Login
The DotNet based CyaX-Sharp loader, also known as ReZer0, is known to spread commodity malware, such as AgentTesla. In recent years, this loader has been referenced numerous times, as it was used in campaigns across the globe. The tale of CyaX-Sharp is interesting, as the takeaways provide insight into the way actors prefer to use the loader. Additionally, it shines a light onto a spot that is not often illuminated: the inner workings of loaders.
This blog is split up into several segments, starting with a brief preface regarding the coverage of loaders in reports. After that, the origin of the loader’s name is explored. Next, the loader’s capabilities are discussed, as well as the automatic extraction of the embedded payload from the loader. Lastly, the bulk analysis of 513 unique loader samples is discussed.
To conceal the malware, actors often use a loader. The purpose of a loader is, as its name implies, to load and launch its payload, thereby starting the next stage in the process. There can be multiple loaders that are executed sequentially, much like a Russian Matryoshka doll in which the smallest doll, which is hidden inside numerous others, is the final payload. The “smallest doll” generally contains the malware’s main capabilities, such as stealing credentials, encrypting files, or providing remote access to the actor.
While there is a lot of research into the actions of the final payload, the earlier stages are just as interesting and relevant. Even though the earlier stages do not contain the capabilities of the malware that is eventually loaded, they provide insight as to what steps are taken to conceal the malware. Blogs generally mention the capabilities of a loader briefly, if at all. The downside here lies in the potential detection rules that others can create with the blog, as the focus is on the final step in the process, whereas the detection should start as soon as possible.
Per best security practices, organizations should protect themselves at every step along the way, rather than only focusing on the outside perimeter. These threat models are often referred to as the, respectively, onion and egg model. The egg’s hard shell is tough to break, but once inside, an attacker has free roam. The onion model opposes the attacker every step of the way, due to its layered approach. Knowing the behavior of the final payload is helpful to detect and block malware although, ideally, the malware would be detected as early on as possible.
This blog focuses on one specific loader family, but the takeaways are valid in a broader sense. The preferred configurations of the actors are useful to understand how loaders can be used in a variety of attacks.
A recent blog by G Data’s Karsten Hahn provides a more in-depth look into malware families ambiguous naming schemes. This loader’s name is also ambiguous, as it is known by several names. Samples are often named based on distinctive characteristics in them. The name CyaX-Sharp is based upon the recurring string in samples. This is, however, exactly why it was also named ReZer0.
When looking at the most used names within the 513 obtained samples, 92 use CyaX-Sharp, whereas 215 use ReZer0. This would make it likely that the loader would be dubbed ReZer0, rather than CyaX-Sharp. However, when looking at the sample names over time, as can be seen in the graph below, the reason why CyaX-Sharp was chosen becomes apparent: the name ReZer0 was only introduced 8 months after the first CyaX-Sharp sample was discovered. Based on this, McAfee refers to this loader as CyaX-Sharp.
Within the settings, one will find V2 or V4. This is not a reference of the loader’s version, but rather the targeted DotNet Framework version. Within the sample set, 62% of the samples are compiled to run on V4, leaving 38% to run on V2.
Each version of the loader contains all core capabilities, which may or may not be executed during runtime, based on the loader’s configuration. The raw configurations are stored in a string, using two pipes as the delimiting value. The string is then converted into a string array using said delimiter. Based on the values at specific indices, certain capabilities are enabled. The screenshots below show, respectively, the raw configuration value, and some of the used indices in a sample (SHA-256: a15be1bd758d3cb61928ced6cdb1b9fa39643d2db272909037d5426748f3e7a4).
The loader can delay its execution by sleeping for a certain number of seconds, use a mutex to ensure it is not already running, display a message box with a custom message, persist itself as a scheduled task, and/or execute a given payload in several ways. The payload can be downloaded from an external location, after which it is started. Alternatively, or additionally, the embedded payload within the loader can be launched. This can be done directly from the loader’s memory with the help of reflective calls, or by hollowing a newly created process. The flowchart below visualizes the process. Note that the dotted line means the linked step can be skipped, depending on the loader’s configuration.
The newly created process is one of the following: MSBuild.exe, vbc.exe, RegSvcs.exe, or a new instance of the loader. The process hollowing code segment seems to be taken from NYAN-x-CAT’s GitHub, as the for-loop to start the process hollowing method is present in both the loader and the linked repository. The way an error is handled is not a standardized method, making the link between the publicly available code very likely. The first image below shows the original code from the repository, whereas the second image shows the code from the loader (SHA-256: a15be1bd758d3cb61928ced6cdb1b9fa39643d2db272909037d5426748f3e7a4)
The loop calls the process hollowing function several times to more easily handle exceptions. In the case of an exception during the process hollowing, the targeted process is killed and the function returns. To try several times, a loop is used.
Even though the loader has changed over time, it maintained the same core structure. Later versions introduced minor changes to existing features. Below, different loader versions will be described, where the length of the string array that contains the loader’s configuration is used to identify different versions. The graph shows the rise and fall for each of the versions.
There are two notable differences in versions where the config array’s size is larger than 29. Some specific samples have slightly different code when compared with others, but I did not consider these differences sizable enough to warrant a new version.
Firstly, the ability to enable or disable the delayed execution of a sample. If enabled, the execution is delayed by sleeping for a predefined number of seconds. In config_29, the delay functionality is always enabled. The duration of the delay is based on the System.Random object, which is instantiated using the default seed. The given lower and upper limits are 45,000 and 60,000, resulting in a value between these limits, which equals in the number of milliseconds the execution should be delayed.
Secondly, the feature to display a custom message in a prompt has been added. The config file contains the message box’ title, text, button style, and icon style. Prompts can be used to display a fake error message to the victim, which will appear to be legitimate e.g. 43d334c125968f73b71f3e9f15f96911a94e590c80955e0612a297c4a792ca07, which uses “You do not have the proper software to view this document” as its message.
To automatically extract the payload and configuration of a given loader, one can recreate the decryption mechanism in a language of choice, get the encrypted data from the loader, and decrypt it. The downside here is the need for an exact copy of the decryption mechanism. If the key were to change, or a slightly different algorithm were to be used, the copy would also need to reflect those changes. To avoid dealing with the decryption method, a different approach can be taken.
This loader mistakenly uses static variables to store the decrypted payload and configuration in. In short, these variables are initialized prior to the execution of the main function of the loader. As such, it is possible to reflectively obtain the value of the two variables in question. A detailed how-to guide can be found on my personal website. The data that was extracted from the 513 samples in the set is discussed in the next section.
The complete set consists of 513 samples, all of which were found using a single Yara rule. The rule focuses on the embedded resource which is used to persist the loader as a scheduled task on the victim’s system. In some cases, the Yara rule will not match a sample, as the embedded resource is obfuscated using ConfuserEx (one example being SHA-256 0427ebb4d26dfc456351aab28040a244c883077145b7b529b93621636663a812). To deobfuscate, one can use ViRb3’s de4dot-cex fork of de4dot. The Yara rule will match with the deobfuscated binary. The graph below shows the number of unique samples over time.
The dates are based on VirusTotal’s first seen date. Granted, this date does not need to represent the day the malware was first distributed. However, when talking about commodity malware that is distributed in bulk, the date is reliable enough.
The sample set that was used is smaller than the total amount of loaders that have been used in the wild. This loader is often not the first stage, but rather an in-memory stage launched by another loader. Practically, the sample set is sizable enough for this research, but it should be noted that there are more unique loader samples in the wild for the given date range than are used in this report.
It is useful to know what the capabilities of a single sample are, but the main area of interest of this research is based upon the analysis of all samples in the set. Several features will be discussed, along with thoughts on them. In this section, all percentages refer to the total of 513 unless otherwise specified.
The loader’s usage is widespread, without a direct correlation towards a specific group or geographical region. Even though some reports mention a specific actor using or creating this loader, the fact that at least one builder has leaked makes attribution to one or more actors difficult. Coupled with the wide variety of targeted industries, as well as the broad geographic targeted areas, it looks like several actors utilise this loader. The goal of this research is not to dig into the actors who utilise this loader, but rather to look at the sample set in general. Appendix A provides a non-exhaustive list of public articles that (at least) mention this loader, in descending chronological order.
The two options to launch a payload, either reflectively or via process hollowing, are widely apart in usage: 90% of all loaders uses process hollowing, whereas only 10% of the samples are launched via reflection. Older versions of the loader sometimes used to reflectively load a decrypted stager from the loader’s resources, which would then launch the loader’s payload via process hollowing. The metrics below do not reflect this, meaning the actual percentage of direct launches might be slightly lower than is currently stated. The details can be viewed in the graph below.
Note that the reflective loading mechanism will default to the process hollowing of a new instance of the loader if any exception is thrown. Only DotNet based files can be loaded reflectively, meaning that other files that are executed this way will be loaded using a hollowed instance of the loader.
The persistence method, which uses a scheduled task to start the loader once the computer boots, is used by 54% of the loaders. This does not mean that the other 46% of the samples are not persisted on the victim’s machine, as a different stage could provide persistence as well. Notable is the date within the scheduled task, which equals 2014-10-25T14:27:44.8929027. This date is, at the time of writing, nearly 2500 days ago. If any of the systems in an organization encounter a scheduled task with this exact date, it is wise to verify its origin, as well as the executable that it points to.
A third of all loaders are configured to avoid running when an instance is already active using a mutex. Similar to the persistence mechanism, a mutex could be present in a different stage, though this is not necessarily the case. The observed mutexes seem to consist of only unaccented alphabetical letters, or [a-zA-Z]+ when written as a regular expression.
Delayed execution is used by nearly 37% of the samples, roughly half of which are config_29, meaning this setting was not configurable when creating the sample. The samples where the delayed execution was configurable, equal nearly 19% of the total. On average, a 4 second delay is used. The highest observed delay is 600 seconds. The graph below shows the duration of the delay, and the frequency.
Note that one loader was configured to have a delay of 0 seconds, essentially not delaying the execution. In most cases, the delayed time is a value that can be divided by five, which is often seen as a round number by humans.
Prior to launching the payload, the loader can perform several checks. A virtual environment can be detected, as well as a sandbox. Roughly 10% of the samples check for the presence of a virtual machine, whereas roughly 11% check if it is executed in a sandbox. Roughly 8% of the 513 samples check for the presence of both, prior to continuing their execution. In other words, 88% of the samples that try to detect a virtual machine, also attempted to detect a sandbox. Vice versa, 74% of the samples that attempted to detect the sandbox, attempted to detect if they were executed on a virtual machine.
The option to disable Windows Defender was mainly present in the earlier samples, which is why only 15% of the set attempts to disable it.
The loader’s final goal is to execute the next stage on the victim’s machine. Knowing what kind of malware families are often dropped can help to find the biggest pain points in your organization’s additional defensive measures. The chart below provides insight into the families that were observed the most. The segment named other contains all samples that would otherwise clutter the overview due to the few occurrences per family, such as the RedLine stealer, Azorult, or the lesser known MrFireMan keylogger.
The percentages in the graph are based on 447 total payloads, as 66 payloads were duplicates. In other words, 66 of the unique loaders dropped a non-unique payload. Of all families, AgentTesla is the most notable, both in terms of frequency and in terms of duplicate count. Of the 66 duplicates, 48 were related to AgentTesla.
Two functions of the loader that are barely used are the message box and the download of a remote payload. The usage of both is, respectively, 1.3% and 0.8%. All of the remote payloads also contained an embedded payload, although one of the four remotely fetching loaders does not contain a URL to download the remote payload from. The external file can be used as an additional module for a next stage, a separate malicious payload, or it can be used to disable certain defense mechanisms on the victim’s device.
Companies using the aforementioned onion security model benefit greatly from the dissection of such a loader, as their internal detection rules can be improved with the provided details. This stops the malware’s execution in its tracks, as is shown in the sequential diagram of McAfee’s detection below.
The techniques that this loader uses are commonly abused, meaning that the detection of a technique such as process hollowing will also prevent the successful execution of numerous other malware families. McAfee’s Endpoint Security (ENS) and Endpoint Detection & Response (EDR) detect the CyaX-Sharp loader every step of the way, including the common techniques it uses. As such, customers are protected against a multitude of families based on a program’s heuristics.
Below, a non-exhaustive chronologically descending list of relevant articles is given. Some articles contain information on the targeted industries and/or target geographical area.
The hashes that are mentioned in this blog are listed below, in order of occurrence. The SHA-1 and SSDeep hashes are also included. A full list of hashes for all 513 samples and their payloads can be found here.
Sample 1
SHA-256: a15be1bd758d3cb61928ced6cdb1b9fa39643d2db272909037d5426748f3e7a4
SHA-1: 14b1a50c94c2751901f0584ec9953277c91c8fff
SSDeep: 12288:sT2BzlxlBrB7d1THL1KEZ0M4p+b6m0yn1MX8Xs1ax+XdjD3ka:O2zBrB7dlHxv0M4p+b50yn6MXsSovUa
Sample 2
SHA-256: 43d334c125968f73b71f3e9f15f96911a94e590c80955e0612a297c4a792ca07
SHA-1: d6dae3588a2a6ff124f693d9e23393c1c6bcef05
SSDeep: 24576:EyOxMKD09DLjhXKCfJIS7fGVZsjUDoX4h/Xh6EkRlVMd3P4eEL8PrZzgo0AqKx/6:EyycPJvTGVijUDlhfEEIUvEL8PrZx0AQ
Sample 3
SHA-256: 0427ebb4d26dfc456351aab28040a244c883077145b7b529b93621636663a812
SHA-1: 8d0bfb0026505e551a1d9e7409d01f42e7c8bf40
SSDeep: 12288:pOIcEfbJ4Fg9ELYTd24xkODnya1QFHWV5zSVPjgXSGHmI:EEj9E/va
The post See Ya Sharp: A Loader’s Tale appeared first on McAfee Blogs.
Hyperautomation is a process where artificial intelligence (AI), machine learning (ML), event-driven software, and other tools are used to automate as many business and IT processes as possible. Forecasted by Gartner to reach $596.6 billion by 20221, hyperautomation and the global software market that enables it show no signs of slowing.
The myriad of technologies used by a typical organization often are not integrated and exist as siloed disparate tools. Hyperautomation aims to reduce this “organizational debt” to improve value and brand. In the context of cybersecurity, a patchwork of stovepipe solutions not only exposes the environment to risk, but also impacts the cyber defender’s ability to fortify the environment and respond to threats at machine speed. Our target is “shift-left” security — leveraging intelligence to enhance predictability and encourage proactive responses to cyber threats.
The rise of telemetry architectures, combined with cloud adoption and data as the “new perimeter,” pose new challenges to cybersecurity operations. Organizations will be forced to contend with increased “security debt” unless we figure out how to optimize, connect, and streamline the solutions. In some cases, we have technologies available to begin this journey (MVISION Insights, MVISION Extended Detection and Response (XDR), MVISION API). In others, our customers demand more. They challenge us to build next-generation platforms to see themselves, see their cyberspace, and understand their cyberspace. Some cyber defenders need more than traditional cyber threat intelligence telemetry to make critical operational impact decisions.
MVISION Insights and MVISION XDR are great starts. It all begins with the build-up of an appropriate telemetry architecture, and McAfee Enterprise’s billion-sensor global telemetry is unmatched. Insights provides an automated means to fortify the environment against emerging threats, weaponizing threat intelligence to take a proactive stance in reducing your attack surface from device to cloud. Why start engaging at an attack’s point of impact when an organization can begin its own awareness at the same point an attacker would? MVISION XDR brings together the fragmented security solutions accumulated over the years, sharing information and coordinating actions to deliver an effective, unified response across every threat vector. Workflows are effortless to orchestrate. The powerful combination of Insights and XDR provides management and visibility of the complete attack lifecycle. Open architectures reinforce our belief that we are better together and facilitate a cybersecurity ecosystem consistent with the concepts of hyperautomation enablement.
Figure 1 – Attack Lifecycle
Where can we go from here? How do we secure tomorrow? From my perspective, we should expand the definition and scope of cybersecurity.
The answer is to look beyond traditional cyber threat telemetry; external factors (environmental, social media, geolocation, law enforcement, etc.) truly matter and are vital in making business impact decisions. Complete operational visibility, and the ability to investigate, research, and rationalize what matters most to make accurate, critical judgments, is the missing link. This is a Cyber Common Operating Picture (COP). A natural extension of our current initiatives within the industry, a COP answers the growing need to provide an integrated cyber defender’s visualization workbench that manages multiple data telemetry sources (beyond cyber threats) and delivers our customers wisdom – a true understanding – regarding their cyberspace on a local, regional, and global scale.
Telemetry data represents change, and telemetry architectures will require new forms of advanced analytics, AI, and ML to make sense of the vast sea of all-source intelligence flowing in from the environment to enhance observations and take definitive action. If we can “shift-left” for cyber threats, we can leverage that same predictability to identify and prepare for the impact of peripheral threats. Open source, custom, and third-party data feeds are widely available and create integration opportunities with emerging markets and capabilities to solve unique challenges typically not associated with our platform:
Non-traditional sensor telemetry, a multitude of feeds, and threat intelligence must be overlayed across the Cyber COP to provide AI-driven predictability modeling for next-gen systems and actionable conclusions. This is a potential future for how hyperautomation can impact cybersecurity; this is orchestrating beyond standard capabilities and expanding the definition and scope of how our complex environments are secured. AI engineering strategies will continue to expand and deliver data analytics at machine speeds.
McAfee Enterprise has always been a proponent of a platform approach to cybersecurity, creating interoperability and extending the security investments its customers have made. Loosely coupled security systems introduce gaps, and hyperautomation aims to solve that at a much larger scale. As we look toward the future, we can collectively build the requirements for the next generation of security solutions and broaden the scope of how we defend against our common adversaries. I am confident that the technologies currently exist to provide the framework(s) of a COP solution for enhanced cyber situational awareness.
Source: 1Gartner Press Release: Gartner Forecasts Worldwide Hyperautomation-Enabling Software Market to Reach Nearly $600 Billion by 2022 (April 28, 2021)
The post Hyperautomation and Cybersecurity – A Platform Approach to Telemetry Architectures appeared first on McAfee Blogs.
Every organization has data moving to the multi-cloud; digital transformation is occurring rapidly, is here to stay, and is impacting every major industry. Organizations are working hard to adopt Zero Trust architectures as their critical information, trade secrets, and business applications are no longer stored in a single datacenter or location. As a result, there is a rapid shift to cloud resources to support dynamic mission requirements, and the new perimeter to defend is data. At its core, Zero Trust is a data-centric model and is fundamental to what McAfee Enterprise offers. In the Public Sector, data has now been classified as a strategic asset – often referred to as the “crown jewels” of an organization. Reinforced by the publication of the DoD Zero Trust Reference Architecture, we have arrived at a crossroads where demonstrating a sound data strategy will be a fundamental requirement for any organization.
All DoD data is an enterprise resource, meaning data requires consistent and uniform protections wherever it is created or wherever it traverses. This includes data transmitted across multi-cloud services, through custom mission applications, and on devices. Becoming a data-centric organization requires that data be treated as the primary asset. It must also be available so that it can be leveraged by other solutions for discovery and analytics purposes. To achieve this, interoperability and uniform data management are strategic elements that underpin many sections of DoD’s official vision of Zero Trust.
Let us dissect how the DoD plans to create a data advantage and where McAfee Enterprise can support these efforts as we explore the four essential capabilities – Architecture, Standards, Governance, and Talent & Culture:
Figure 1 – DoD Data Strategy Framework
McAfee Enterprise’s open architectural methodology emphasizes the efficiencies that cloud adoption and open frameworks can offer. The ability to leverage agile development and continuously adapt to dynamic mission requirements – faster than our adversaries – is a strategic advantage. Data protection and cloud posture, however, must not take a back seat to innovation.
The rapid pace of cloud adoption introduces new risks to the environment; misconfigurations and mistakes happen and are common. Vulnerabilities leave the environment exposed as DevOps tends to leverage open-source tools and capabilities. Agile development introduces a lot of moving parts as applications are updated and changed at an expedited pace and based on shorter, prescriptive measures. Customers also utilize multiple cloud service providers (CSP) to fit their mission needs, so consistent and uniform data management across all the multi-cloud services is a necessity. We are at a pivotal inflection point where native, built-in CSP protections have introduced too much complexity, overhead, and inconsistency. Our data security solution is a holistic, open platform that enforces standardized protections and visibility across the multi-cloud.
Together with our partners, we support the architecture requirements for data-centric organizations and take charge as the multi-cloud scales. Several items – visibility and control over the multi-cloud, device-to-cloud data protection, cloud posture, user behavior and insider threat – play into our strengths while organic partner integrations (e.g., ZTNA) further bolster the Zero Trust narrative and contribute to interoperability requirements. We are better together and can facilitate an open architecture to meet the demands of the mission.
DoD requires proven-at-scale methods for managing, representing, and sharing data of all types, and an open architecture should be used wherever possible to avoid stovepiped solutions and facilitate an interoperable security ecosystem. Past performance is key, and McAfee Enterprise has a long track record of delivering results, which is crucial as the DoD moves into a hybrid model of management.
Data comes in many forms, and the growth of telemetry architectures requires machines to do more with artificial intelligence and machine learning to make sense of data. How do we share indicators of compromise (IoCs) so multiple environments – internal and external – can leverage intelligence from other organizations? How do we share risks in multi-clouds and ensure data is secured in a uniform manner? How do we weaponize intelligence to shift “left of boom” and eliminate those post-compromise autopsies? Let’s explore how McAfee Enterprise supports data standards.
Made possible by Data Exchange Layer (DXL) and a strategic partner, the sharing of threat intelligence data has proven successful. Multiple environments participate in a security-connected ecosystem where an “attack against one is an attack against all” and advanced threats are detected, stopped, and participants are inoculated in near real-time. This same architecture scales to the hybrid cloud where the workloads in cloud environments can benefit from broad coverage.
Furthermore, DXL was built as open source to foster integrations and deliver cohesive partner solutions to promote interoperability and improve threat-informed intelligence. All capabilities speak the same language, tip and cue, and provide much greater return on investment. Consider the sharing of cloud-derived threats. No longer should we be limited to traditional hashes or IoCs. Perhaps we should share risky or malicious cloud services and/or insider threats. Maybe custom-developed solutions should leverage our MVISION platform via API to take advantage of the rich global telemetry and see what we see.
Our global telemetry is unmatched and can be leveraged to organizations’ advantage to proactively fortify the device-to-cloud environment, effectively shifting security to the “left” of impact. This is all done through the utilization of MVISION Insights. Automated posture assessments pinpoint where potential gaps in an organization’s countermeasures may exist and provide the means to take proactive action before it is hit. Through MVISION Insights, cyber operators can learn about active global campaigns, emerging threats, and whether an organization is in the path – or even the target. Leadership can grasp the all-important risk metric and deliver proof that the security investments are working and operational. Combined with native MITRE ATT&CK Framework mappings – an industry standard being mapped across our portfolio – this proactive hardening is a way we use threat telemetry to customers’ advantage.
Standardized data protection, end-to-end, across all devices and multi-cloud services is a key tenant of the DoD Data Strategy. Protecting data wherever it lives or moves, retaining it within set boundaries and making it available to approved users and devices only, and enforcing consistent controls from a single, comprehensive solution spanning the entire environment is the only data security approach. This is what Unified Cloud Edge (UCE) does. This platform’s converged approach is tailored to support DoD’s digital transformation to the multi-cloud and its journey to a data-centric enterprise.
DoD’s data governance element is comprised of the policies, procedures, frameworks, tools, and metrics to ensure data is managed at all levels, from when it is created to where it is stored. It encompasses increased data oversight at multiple levels and ensures that data will be integrated into future modernization initiatives. Many organizations tend to be driven by compliance requirements (which typically outweigh security innovation) unless there is an imminent mission need; we now have the compliance requirement. Customers will need to demonstrate a proper data protection and governance strategy as multi-cloud adoption matures. What better way to incorporate Zero Trust architectures than by leveraging UCE? Remember, this is beyond the software defined perimeter.
McAfee Enterprise can monitor, discover, and analyze all the cloud services leveraged by users – both approved and unapproved (Shadow IT) – and provide a holistic assessment. Closed loop remediation ensures organizations can take control and govern access to the unapproved or malicious services and use the information to lay the foundation for building effective data protection policies very relevant to mission needs.
Granular governance and control – application-level visibility – by authenticated users working within the various cloud services is just as important as controlling access to them. Tight API integrations with traditional SaaS services guarantee only permitted activities occur. With agile development on the rise, it is just as important that the solution is flexible to control these custom apps in the same way as any commercial cloud service. Legacy mission applications are being redesigned to take advantage of cloud scale and efficiency; McAfee Enterprise will not impose limits.
Governance over cloud posture is equally important, and customers need to ensure the multi-cloud environment is not introducing any additional source of risk. Most compromises are due to misconfigurations or mistakes that leave links, portals, or directories open to the public. We evaluate the multi-cloud against industry benchmarks and best practices, provide holistic risk scoring, and provide the means to remediate these findings to fortify an organization’s cloud infrastructure.
Unified data protection is our end goal; it is at the core of what we do and how we align to Zero Trust. Consistent protections and governance over data wherever it is created, wherever it goes, from device to multi-cloud. The same engine is shared across the environment and provides a single place for incidents and management across the enterprise. Customers can be confident that all data will be tracked and proper controls enforced wherever its destination may be.
Becoming a data-centric organization will require a cultural change. Decision-making capabilities will be empowered by data and analytics as opposed to experienced situations and scenarios (e.g., event response). Machine learning and artificial intelligence will continue to influence processes and procedures, and an open ecosystem is needed to facilitate effective collaboration. Capabilities designed to foster interoperability and collaboration will be the future. As more telemetry is obtained, solutions must support the SOC analyst with reduced noise and provide relevant, actionable data for swift decision-making.
At McAfee Enterprise, we hear this. UCE provides simplified management over the multi-cloud to ensure consistent and unified control over the environment and the data. No other vendor has the past performance at scale for hybrid, centralized management. MVISION Insights ensures that environments are fortified against emerging threats, allowing the cyber operators to focus on the security gaps that can leave an organization exposed. Threat intelligence sharing and an open architecture has been our priority over the past several years, and we will continue to enrich and strengthen that architecture through our platform approach. There is no silver bullet solution that will meet every mission requirement, but what we can collectively do is ensure we are united against our adversaries.
Data and Zero Trust will be at the forefront as we move forward into adopting cloud in the public sector. There is a better approach to security in this cloud-first world. It is a mindset change from the old perimeter-oriented view to an approach based on adaptive and dynamic trust and access controls. McAfee’s goal is to ensure that customers can support their mission objectives in a secure way, deliver new functionality, improved processes, and ultimately give better return on investments.
We are better together.
The post Data as a Strategic Asset – Securing the New Perimeter in the Public Sector appeared first on McAfee Blogs.
This news has been some time in the making, and I’m terrifically excited to share it.
As of July 27th, we take a decisive step forward, one where McAfee places its sole focus on consumers. People like you. This marks the day we officially divest our enterprise business and dedicate ourselves to protecting people so they can freely enjoy life online.
This move reflects years of evolution, time spent re-envisioning what online protection looks like in everyday life—how to make it stronger, easier to use, and most importantly, all the ways it can make you feel safe and help you stay that way.
In the coming days, you’ll see your experience with us evolve dramatically as well. You’ll see advances in our online protection that look, feel, and act in bold new ways. They will put you in decisive control of your identity and privacy, all in a time where both are so infringed upon. And you’ll also see your protection get simpler, much simpler, than before.
Today, I’d like to give you a preview of what’s ahead.
First, these changes are inspired by you. From feedback, research, interviews, and even having some of you invite us into your homes to show us how you live life online, you’ve made it clear what’s working and what isn’t. You’ve also shared what’s on your mind—your thoughts on technology’s rapid growth, the concerns you have for your children, and the times where life online makes you feel vulnerable.
We’re here to change things for the better. And here’s why …
Our lives are more fluid and mobile than ever before. From the palm of our hand, we split the cost of dinner, purchase birthday gifts, dim the lights in our living room, warm up the car on a winter morning, and far more. In many ways, our smartphones are the remote control for our lives. From managing our finances to controlling our surroundings, we’re increasing our use of technology to get things done and make things happen. Could any of us have imagined this when the first smartphones rolled out years ago?
Without question, we’re still plenty reliant on our computers and laptops too. Our recent research showed that we’re looking forward to using them in addition to our phones for telemedicine, financial planning, and plenty of personal shopping—each representing major upticks in usage than in years before, up to 74 percent more in some cases.
Yet what’s the common denominator here? You. Whatever device you’re using, at the center of all that activity is you. You’re the one who’s getting things done, making things happen, or simply passing some time with a show. So, while the device remains important, what’s far more important is you—and the way you’re using your device for ever-increasing portions of your life. Safely. Confidently. Easily.
Taken together, the time to squarely focus on protecting people is now. A new kind of online security is called for, one that can protect you as you go online throughout your day in a nearly constant and seamless fashion. We’ve dedicated ourselves to making that happen. And you’ll soon see what that looks like.
So how can you expect this evolution to take shape? You’ll see it in three significant ways:
1. Personalized experience. We’re building security that protects you effortlessly wherever your day takes you. From device to device, place to place, and all the experiences online in between. Think of our approach to online protection like Netflix, which used to be a physical service where you waited in queue for that next episodic DVD of Lost to get mailed to you. Now your shows follow you and stream anywhere, no matter what device you’re on. It’s the same thing with our security. It will recognize you and protect you whether you’re at home or by the pool on vacation, on your laptop, or your phone, with one consistent experience. Again, it’s all about you. Keeping you protected as you enjoy every perk and convenience of life online.
2. Intelligent experience. The next evolution builds on personalization and takes it a step further. This is security that understands when you and your personal info is at risk and then takes intelligent steps to protect you. This could be your smartphone automatically connecting to VPN when you’re at the airport, keeping you safe from prying eyes on public networks. It could also be alerts to you if your personal info is compromised so you can take steps to protect it. Or it could be a simple suggestion to help keep you safe while browsing, shopping, or banking online. In all, it’s intelligence that helps you stay safe and make safe choices.
3. Simpler experience. With this personalization and intelligence in place, you can protect everyone in your family far more easily than ever. It becomes practically automatic. Regardless of their age, interests, or how much they know about technology, this simplified approach to online security makes smart choices for you and your family wherever possible, steering them clear of threats and keeping everyone safer as a result.
Us at your side. New and existing customers alike will still benefit from McAfee’s award-winning technology as you always have. Further advances and features will roll out to you as part of the regular updates as they become available for your subscription. In all, you’ll always have the latest and greatest benefits of your product with us.
As for our future, expect more to come. Your confidence in us both fuels and informs these leaps ahead. Thank you as always for choosing us for your protection. It allows us to invest in breakthroughs that keep you safe against new and evolving threats, just as we have as a market leader for years.
The new McAfee is focused on you. It’s a bold new world of protection online, where you are in control of your identity and privacy, where you have intelligence that offers right protection in the right moment, where you can simply feel safe, and where you’re ultimately free to enjoy your life online at every turn.
Here’s to what’s next. And I can’t wait for you to experience it.
To stay updated on all things McAfee and on top of the latest consumer and mobile security threats, follow @McAfee_Home on Twitter, subscribe to our newsletter, listen to our podcast Hackable?, and ‘Like’ us on Facebook.
The post The New McAfee: A Bold New World of Protection Online appeared first on McAfee Blogs.
Co-written with Northwave’s Noël Keijzer.
For a long time, ransomware gangs were mostly focused on Microsoft Windows operating systems. Yes, we observed the occasional dedicated Unix or Linux based ransomware, but cross-platform ransomware was not happening yet. However, cybercriminals never sleep and in recent months we noticed that several ransomware gangs were experimenting with writing their binaries in the cross-platform language Golang (Go).
Our worst fears were confirmed when Babuk announced on an underground forum that it was developing a cross-platform binary aimed at Linux/UNIX and ESXi or VMware systems. Many core backend systems in companies are running on these *nix operating systems or, in the case of virtualization, think about the ESXi hosting several servers or the virtual desktop environment.
We touched upon this briefly in our previous blog, together with the many coding mistakes the Babuk team is making.
Even though Babuk is relatively new to the scene, its affiliates have been aggressively infecting high-profile victims, despite numerous problems with the binary which led to a situation in which files could not be retrieved, even if payment was made.
Ultimately, the difficulties faced by the Babuk developers in creating ESXi ransomware may have led to a change in business model, from encryption to data theft and extortion.
Indeed, the design and coding of the decryption tool are poorly developed, meaning if companies decide to pay the ransom, the decoding process for encrypted files can be really slow and there is no guarantee that all files will be recoverable.
McAfee’s EPP solution covers Babuk ransomware with an array of prevention and detection techniques.
McAfee ENS ATP provides behavioral content focusing on proactively detecting the threat while also delivering known IoCs for both online and offline detections. For DAT based detections, the family will be reported as Ransom-Babuk!. ENS ATP adds 2 additional layers of protection thanks to JTI rules that provide attack surface reduction for generic ransomware behaviors and RealProtect (static and dynamic) with ML models targeting ransomware threats.
Updates on indicators are pushed through GTI, and customers of Insights will find a threat-profile on this ransomware family that is updated when new and relevant information becomes available.
Initially, in our research the entry vector and the complete tactics, techniques and procedures (TTPs) used by the criminals behind Babuk remained unclear.
However, when its affiliate recruitment advertisement came online, and given the specific underground meeting place where Babuk posts, defenders can expect similar TTPs with Babuk as with other Ransomware-as-a-Service families.
In its recruitment posting Babuk specifically asks for individuals with pentest skills, so defenders should be on the lookout for traces and behaviors that correlate to open source penetration testing tools like winPEAS, Bloodhound and SharpHound, or hacking frameworks such as CobaltStrike, Metasploit, Empire or Covenant. Also be on the lookout for abnormal behavior of non-malicious tools that have a dual use, such as those that can be used for things like enumeration and execution, (e.g., ADfind, PSExec, PowerShell, etc.) We advise everyone to read our blogs on evidence indicators for a targeted ransomware attack (Part1, Part2).
Looking at other similar Ransomware-as-a-Service families we have seen that certain entry vectors are quite common amongst ransomware criminals:
When it comes to the actual ransomware binary, we strongly advise updating and upgrading your endpoint protection, as well as enabling options like tamper protection and rollback. Please read our blog on how to best configure ENS 10.7 to protect against ransomware for more details.
Learn more about how Babuk is transitioning away from an encryption/ransom model to one focused on pure data theft and extortion in our detailed technical analysis.
The post Babuk: Biting off More than they Could Chew by Aiming to Encrypt VM and *nix Systems? appeared first on McAfee Blogs.
This week, McAfee took an exciting new step in our journey—we are now a pure-play consumer company. What does that mean for consumers? It means that McAfee will be able to focus 100% of our talent and expertise on innovation and development that directly enables and improves the products and services that protect you and your family.
It’s the right time to take that step. Today, we use technology in every aspect of our lives, from education to recreation and entertainment to transportation. We have connected devices in our cars, in our pockets, and in our houses. In fact, the average U.S. household has 25 connected devices, and this number will continue to grow as more connected devices hit the market. We are also on the precipice of new connectivity technology, such as 5G, that will enable devices to access larger amounts of data, faster, and from more places.
All this technology makes our lives easier and more enriching in some way, whether it’s the ability to do our banking online or ordering groceries online or even having a consultation with our physician online. Our behaviors have changed during the past sixteen months and our need for online protection has changed with the times.
Our online world is rapidly evolving, and as McAfee’s Chief Technology Officer, part of my job is to ensure that you and your family can use the latest, cutting-edge technology with the confidence and peace of mind that you are protected.
The technology required to defend consumers against the latest threats requires new levels of sophistication. It’s important that we don’t confuse sophistication with complexity. Part of my mission for McAfee is to package the world’s most effective, highly sophisticated cybersecurity technology in a form that is accessible, usable, and consumable by everyday users—people and their families
So as McAfee places its entire focus on consumers, what that really means is that now the focus is on you. Your life online, and the ways you use it to run your home, keep tabs on your finances, split dinner with friends, chat with your children’s teachers, and binge on your favorite shows over a rainy weekend. More than that, we’re here to protect you, because you are at the center of all these things and more. Our aim is to bring you breakthrough advances in online protection so that you can freely enjoy life online. And everyone here at McAfee is looking forward to bringing them to you.
The post It’s All About You: McAfee’s New All-Consumer Focus appeared first on McAfee Blogs.
Written by Shuborno, Principal Engineer
At McAfee, architects and engineers continuously have opportunities to make decisions that impact customers and propel exciting and meaningful careers. They also work with leaders focused on supporting their learning and growth. These truths have been constant and driving forces for me throughout my 15+ years with the company.
Today, I am a Principal Engineer at McAfee. My job is to translate product and customer goals into the technology we must build to enable and sustain those goals. It is challenging, fulfilling work that impacts 40 million customers around the world and motivates me every day.
This role is also a high in my personal career journey, one that started with a McAfee internship while I was a student at the University of Waterloo in Ontario, Canada.
Supportive leadership is an important, and differentiating, element of McAfee’s culture. Being promoted to Principal Engineer was, of course, an incredibly proud moment in my career, but the support and encouragement of my managers and mentors helped me get there.
When I moved into the Software Architect role, I met with the head of Consumer Engineering who — to my surprise — arranged for the Chief Architect to mentor me. Things took off from there.
Jeremy, one of my mentors, helped me realize the impact I could make by asking a simple question: “If there is something important that needs to be done, why aren’t you doing it?”
That encouragement, support, and coaching gave me the confidence and motivation to achieve the Principal Engineer career goal. It also helped me understand the importance of supportive leaders focused on helping their teams learn, grow, and succeed.
Beyond the office, McAfee leaders supported my growth, too. Early on as an architect, my manager encouraged me to get involved with Toastmasters, an organization that teaches public speaking and leadership skills. I’ve used skills gained there when presenting to fellow architects and engineers, C-level executives including the CTO, as well as during my Principal Engineer Committee Panel presentation. (Today, I’m also the Vice President of Education for my local Toastmasters Club!)
The leadership support I’ve experienced at McAfee enabled me to learn, grow, and thrive, inside and outside the office. I know that the same support will be available for you — and anyone who joins the McAfee team — because when McAfee employees thrive, McAfee thrives, too.
Are you considering joining our team? McAfee takes great pride in a culture that promotes personal growth and professional success. Learn more about our jobs. Subscribe to job alerts.
The post My Journey from Intern to Principal Engineer appeared first on McAfee Blogs.
In 2021 ransomware attacks have been dominant among the bigger cyber security stories. Hence, I was not surprised to see that McAfee’s June 2021 Threat report is primarily focused on this topic.
This report provides a large range of statistics using the McAfee data lake behind MVISION Insights, including the Top MITRE ATT&CK Techniques. In this report I highlight the following MITRE techniques:
I also want to highlight one obvious technique which remains common across all ransomware attacks at the end of the attack lifecycle:
Traditional defences based on anti-malware signatures and web protection against known malicious domains and IP addresses can be insufficient to protect against these techniques. Therefore, for the rest of this article, I want to cover a few recent McAfee innovations which can make a big difference in the fight against ransomware.
The following three ransomware techniques are linked to web access:
Moreover, most ransomware attacks require some form of access to a command-and-control server to be fully operational.
McAfee Remote Browser Isolation (RBI) ensures no malicious web content ever even reaches enterprise endpoints’ web browsers by isolating all browsing activity to unknown and risky websites into a remote virtual environment. With spear phishing links, RBI works best when running the mail client in the web browser. The user systems cannot be compromised if web code or files cannot run on them, making RBI the most powerful form of web threat protection available. RBI is included in most McAfee United Cloud Edge (UCE) licenses at no additional cost.
Figure 1. Concept of Remote Browser Isolation
McAfee Client Proxy (MCP) controls all web traffic, including ransomware web traffic initiated without a web browser by tools like MEGAsync and Rclone. MCP is part of McAfee United Cloud Edge (UCE).
The following ransomware techniques are linked to fileless attacks:
Many ransomware attacks also use PowerShell.
Figure 2. Example of an attack kill chain with fileless
McAfee provides a large range of technologies which protect against fileless attack methods, including McAfee ENS (Endpoint Security) Exploit prevention and McAfee ENS 10.7 Adaptive Threat Protection (ATP). Here are few examples of Exploit Prevention and ATP rules:
Regarding the use on Mimikatz in the example above, the new McAfee ENS 10.7 ATP Credential Theft Protection is designed to cease attacks against Windows LSASS so that you do not need to rely on the detection of Mimikatz.
Figure 3. Example of Exploit Prevention rules related to Mimikatz
ENS 10.7 ATP is now included in most McAfee Endpoint Security licenses at no additional cost.
To prevent initial access, you also need to reduce the risks linked to the following technique:
For example, RDP (Windows Remote Desktop Protocol) is a common initial access used by ransomware attacks. You may have a policy that already prohibits or restricts RDP but how do you know it is enforced on every endpoint?
With MVISION EDR (Endpoint Detection and Response) you can perform a real time search across all managed systems to see what is happening right now.
Figure 4. MVISION EDR Real-time Search to verify if RDP is enabled or disabled on a system
Figure 5. MVISION EDR Real-time Search to identify systems with active connections on RDP
MVISION EDR maintains a history of network connections inbound and outbound from the client. Performing an historical search for network traffic could identify systems that actively communicated on port 3389 to unauthorized addresses, potentially detecting attempts at exploitation.
MVISION EDR also enables proactive monitoring by a security analyst. The Monitoring Dashboard helps the analyst in the SOC quickly triage suspicious behavior.
For more EDR use cases related to ransomware see this blog article.
With MVISION Insights you do not need to wait for the latest McAfee Threat Report to be informed on the latest ransomware campaigns and threat profiles. With MVISION Insights you can easily meet the following use cases:
These use cases are covered in the webinar How to fight Ransomware with the latest McAfee innovations.
Regarding the following technique from the McAfee June 2021 Threat Report:
Credentials from Web Browsers (Credential Access)
MVISION Insights can display the detections in your environment as well as prevalence statistics.
Figure 6. Prevalence statistics from MVISION Insights on the LAZAGNE tool
MVISION Insights is included in several Endpoint Security licenses.
Now we are left with the last technique in the attack lifecycle:
McAfee ENS 10.7 Adaptive Threat Protection (ATP) provides dynamic application containment of suspicious processes and enhanced remediation with an automatic rollback of the ransomware encryption.
Figure 7. Configuration of Rollback remediation in ENS 10.7
You can see how files impacted by ransomware can be restored through Enhanced Remediation in this video. For more best practices on tuning Dynamic Application Containment rules, check the knowledge base article here.
Last year McAfee released this blog article covering additional capabilities from McAfee Endpoint Security (ENS), Endpoint Detection and Response (EDR) and the Management Console (ePO) against ransomware including:
To increase your protection against ransomware you might already be entitled to:
If you are, you should start using them as soon as possible, and if you are not, contact us.
The post Fighting new Ransomware Techniques with McAfee’s Latest Innovations appeared first on McAfee Blogs.
The overarching threat facing cyber organizations today is a highly skilled asymmetric enemy, well-funded and resolute in his task and purpose. You never can exactly tell how they will come at you, but come they will. It’s no different than fighting a kinetic foe in that, before you fight, you must choose your ground and study your enemy’s tendencies.
A lot of focus has been placed on tools and updating technology, but often we are pushed back on our heels and find ourselves fighting a defensive action.
But what if we change? How do we do that?
The first step is to study the battlefield, understand what you’re trying to protect and lay down your protection strategy. Pretty basic right??
Your technology strategy is very important, but you must embrace and create a thorough Cyber Threat Intelligence (CTI) doctrine which must take on many forms.
First, there is data, and lots of it. However, the data must take specific forms to research and detect nascent elements where the adversary is attempting to catch you napping or give you the perception that the activity you see is normal.
As you pool this data, it must be segmented into layers and literally mapped to geographic locations across the globe. The data is classified distinctly as malicious and reputations are applied. This is a vital step in that it enables analytical programs, along with human intelligence analysts to apply the data within intelligence reports which themselves can take on many forms.
Once the data takes an analytic form, then it allows organizations to forensically piece together a picture of an attack. This process is painstakingly tedious but necessary to understand your enemy and his tendencies. Tools are useful, but it’s always the human in the loop that will recognize the tactical and strategic implications of an adversary’s moves. Once you see the picture, it becomes real, and then you’re able to prepare your enterprise for the conflict that follows.
Your early warning and sensing strategy must incorporate this philosophy. You must sense, collect, exploit, process, produce and utilize each intelligence product that renders useful information. It’s this process that will enable any organization to move decisively to and stay “left of boom”.
The McAfee Advanced Programs Group (APG) was created eight years ago to support intelligence organizations that embrace and maintain a strong CTI stance. Its philosophy is to blend people, processes, data and a strong intelligence heritage to enable our customers to understand the cyber battlefield to proactively protect, but “maneuver” when necessary to avoid an attack.
APG applies three key disciplines or mission areas to provide this support.
First, we developed an internal tool called the Advanced Threat Landscape Analysis System (ATLAS). This enables our organization to apply our malicious threat detections to a geospatial map display to see where we’re seeing malicious data. ATLAS draws from our global network of billions of threat sensors to see trillions of detections each day, but enables our analysts to concentrate on the most malicious activity. Then we’re better able to research and report accurate threat landscape information.
The second leg in the stool is our analytical staff, the true cyber ninjas that apply decades of experience supporting HUMINT operations across the globe and a well-established intelligence-based targeting philosophy to the cyber environment. The result is a true understanding of the cyber battlefield enabling the leadership to make solid “intelligence-based” decisions.
Finally, the third leg is our ability to develop custom solutions and interfaces to adapt in a very custom way our ability to see and study data. We have the ability to leverage 2.8 billion malicious detections, along with 20 other distinct malicious feeds, to correlate many different views, just not the McAfee view. We interpret agnostically.
These three legs provide APG a powerful CTI advantage allowing our customers to adapt and respond to events by producing threat intelligence dynamically. When using this service it allows the customer to be fully situationally aware in a moments notice (visual command and control). Access to the data alone is an immense asset to any organization. This allows each customer not only to know what their telemetry is, but also provides real time insights into the entire world ecosystem. Finally, the human analysis alone is immensely valuable. It allows for the organizations to read and see/understand what it all means (the who, what, where and why). “The so what!!”
The post An Overall Philosophy on the Use of Critical Threat Intelligence appeared first on McAfee Blogs.
This blog was written byVaradharajan Krishnasamy, Karthickkumar, Sakshi Jaiswal
Ransomware attacks are one of the most common cyber-attacks among organizations; due to an increase in Ransomware-as-a-service (RaaS) on the black market. RaaS provides readily available ransomware to cyber criminals and is an effective way for attackers to deploy a variety of ransomware in a short period of time.
Usually, RaaS model developers sell or rent their sophisticated ransomware framework on the black market. After purchasing the license from the ransomware developer, attackers spread the ransomware to other users, infect them, encrypt files, and demand a huge ransom payment in Bitcoin. Also, there are discounts available on the black market for ransomware frameworks in which the ransom money paid is shared between developers and the buyer for every successful extortion of ransom from the victims. These frameworks reduce the time and effort of creating a new ransomware from scratch using latest and advanced programming languages.
REvil is one of the most famous ransomware-as-a-service (RaaS) providers. The group released the Sodinokibi ransomware in 2019, and McAfee has since observed REvil using a DLL side loading technique to execute ransomware code. The actual ransomware is a dropper that contains two embedded PE files in the resource section. After successful execution, it drops two additional files named MsMpEng.exe and MpSvc.dll in the temp folder. The file MsMpEng.exe is a Microsoft digitally signed file having a timestamp of March 2014 (Figure 1).
Figure-1: Image of Microsoft Digitally signed File
The malware uses DLL side loading to execute the ransomware code. This technique allows the attacker to execute malicious DLLs that spoof legitimate ones. This technique has been used in many APTs to avoid detection. In this attack, MsMpEng.exe loads the functions of MpSvc.dll during the time of execution. However, the attacker has replaced the clean MpSvc.dll with the ransomware binary of the same name. The malicious DLL file has an export function named ServiceCrtMain, which is further called and executed by the Microsoft Defender file. This is a clever technique used by the attacker to execute malicious file using the Microsoft digitally signed binary.
Figure-2: Calling Export function
The ransomware uses the RC4 algorithm to decrypt the config file which has all the information that supports the encryption process.
Figure-3: REvil Config File
Then it performs a UI language check using GetSystemDefaultUILanguage/GetUserDefaultUILanguage functions and compares it with a hardcoded list which contains the language ID of several countries as shown in below image.
Figure-4: Language Check
Countries excluded from this ransomware attack are mentioned below:
| GetUserDefaultUILanguage | Country name |
| 0x419 | Russian |
| 0x422 | Ukranian |
| 0x423 | Belarusian |
| 0x428 | Tajik (Cyrilic from Tajikistan) |
| 0x42B | Armenian |
| 0x42C | Azerbaijani (Latin from Azerbaijan) |
| 0x437 | Georgian |
| 0x43F | Kazakh from Kazakhastan |
| 0x440 | Kyrgyzstan |
| 0x442 | Turkmenistan |
| 0x443 | Latin from Uzbekistan |
| 0x444 | Tatar from Russia Federation |
| 0x818 | Romanian from Moldova |
| 0x819 | Russian from Moldova |
| 0x82C | Cyrilic from Azerbaijan |
| 0x843 | Cyrilic from Uzbekistan |
| 0x45A | Syriac |
| 0x281A | Cyrilic from Serbia |
Additionally, the ransomware checks the users keyboardlayout and it skips the ransomware infection in the machine’s which are present in the country list above.
Figure-5: Keyboardlayout check
Ransomware creates a Global mutex in the infected machine to mark its presence.
Figure-6: Global Mutex
After creating the mutex, the ransomware deletes the files in the recycle bin using the SHEmptyRecycleBinW function to make sure that no files are restored post encryption.
Figure-7: Empty Recycle Bin
Then it enumerates all the active services with the help of the EnumServicesStatusExW function and deletes services if the service name matches the list present in the config file. The image below shows the list of services checked by the ransomware.
Figure-8: Service List check
It calls the CreateToolhelp32Snapshot, Process32FirstW and Process32NextW functions to enumerate running processes and terminates those matching the list present in the config file. The following processes will be terminated.
Then, it encrypts files using the Salsa20 algorithm and uses multithreading for fast encryption of the files. Later, background wallpaper will be set with a ransom message.
Figure-9: Desktop Wallpaper
Finally, the ransomware displays ransom notes in the victim’s machine. Below is an image of readme.txt which is dropped in the infected machine.
Figure-10: Ransom Note
| Type | Value | Detection Name | Detection Package Version (V3) |
| Loader | 5a97a50e45e64db41049fd88a75f2dd2 | REvil.f | 4493 |
| Dropped DLL | 78066a1c4e075941272a86d4a8e49471 | REvil.e | 4493 |
Expert rules allow McAfee customers to extend their coverage. This rule covers this REvil ransomware behaviour.
| Technique ID | Tactic | Technique Details |
| T1059.003 | Execution | Command and Scripting Interpreter |
| T1574.002 | DLL Side-Loading | Hijack Execution Flow |
| T1486 | Impact | Data Encrypted for Impact |
| T1036.005 | Defense Evasion | Masquerading |
| T1057 | Discovery | Process Discovery |
| T1082 | Discovery | System Information Discovery |
McAfee observed that the REvil group has utilized oracle web logic vulnerability (CVE-2019-2725) to spread the ransomware last year and used kaseya’s VSA application recently for their ransomware execution, with the help of DLL sideloading. REvil uses many vulnerability applications for ransomware infections, however the encryption technique remains the same. McAfee recommends making periodic backups of files and keeping them isolated off the network and having an always updated antivirus in place.
The post REvil Ransomware Uses DLL Sideloading appeared first on McAfee Blogs.
Small business owners are getting a special deal on their online protection through a partnership between McAfee and Visa. With new ways of working creating online opportunities and risks for small business owners, McAfee and Visa have come together to offer comprehensive protection for a changed business landscape.
Designed to help you minimize costs and unexpected interruptions to your business, McAfee® Security for Visa cardholders provides award-winning antivirus, ransomware, and malware protection for all your company devices including PCs, smartphones, and tablets on all major platforms. Visa Small Business cardholders automatically save up to 40% with a 24-month package and up to 60% with a 12-month offer.
Safety features include:
McAfee’s security savings bundle is also part of Visa’s commerce in a box initiative, which has launched in six U.S. cities (D.C., Detroit, Atlanta, Miami, Los Angeles and Chicago). This program features a curated selection of offers, discounts, and bundles from Visa’s Authorize.net and Visa partners designed to help small businesses with what they need to move their business forward digitally — from accepting digital payments and building an eCommerce site to marketing to their audience in new ways and providing online marketing tools to run and protect their business.
The post Small Businesses Save Up to 60% in McAfee and Visa Partnership appeared first on McAfee Blogs.
The latest guidance in the Executive Order on Improving the Nation’s Cybersecurity (EO), Section 2, discusses removing the barriers to sharing threat information. It describes how security partners and service providers are often hesitant or contractually unable to share information about a compromise. The EO helps ensure that security partners and service providers can share intelligence with the government and requires them to share certain breach data with executive level departments and agencies responsible for investigating and remediating incidents, namely CISA, the FBI, and the IC. This approach will enable better comprehensive threat visibility across the Executive Branch departments and agencies to promote early detection and coordinated response actions. Indeed, the threat information sharing section will help enhance the public-private sector partnership that McAfee, and our colleagues in the cyber security industry are committed to supporting. To achieve this goal the EO requires:
The EO is a positive first step towards improving incident awareness at a macro level, though the EO would be even more impactful if it pushed government agencies to share more threat information with the private sector. The U.S. government represents an incredibly large attack surface and being able to identify threats early in one agency or department may very well serve to protect other agencies by enabling stronger predictive and more proactive defenses. While a government-built threat intelligence data lake is a critical first step, I think a logical next step should be opening the focus of threat intelligence sharing to be both real-time and bi-directional.
The EO focuses on the need for the private sector to improve its information sharing and collaboration with the government. However, the guidance is focused more on “post-breach” and unidirectional threat sharing. Real-time, not just “post-breach,” threat sharing improves the speed and effectiveness of countermeasures and early detection. Bi-directional data sharing opens possibilities for things like cross-sector environmental context, timely and prescriptive defensive actions, and enhanced remediation and automation capabilities. Harnessing real-time sector-based threat intelligence is not a unique concept; companies like McAfee have started to deliver on the promise of predictive security using historical threat intelligence to guide proactive security policy decision making.
Real-time threat sharing will make one of the EO’s additional goals, Zero Trust, ultimately more achievable. Zero Trust requires a dynamic analysis layer that will continuously evaluate user and device trust. As environmental variables change, so should the trust and ultimately access and authorization given. If the intent of threat intelligence sharing is to identify potentially compromised or risky assets specific to emerging campaigns, then it stands to reason that the faster that data is shared, the faster trust can be assessed and modified to protect high-value assets.
McAfee has identified the same benefits and challenges as the government for targeted threat intelligence and has developed a useful platform to enable robust threat sharing. We understand the value of sector specific data acting as an early indicator for organizations to ensure protection. Focusing on our own threat intelligence data lakes, we deliver on the promise of sector-specific intelligence by identifying targeted campaigns and threats and then correlating those campaigns to protective measures. As a result, government agencies now have the advantage of predicting, prioritizing, and prescribing appropriate defense changes to stay ahead of industry-focused emerging campaigns. We call that capability MVISION Insights.
This approach serves to drive home the need for collaborative shared threat intelligence. McAfee’s broad set of customers across every major business sector, combined with our threat research organization and ability to identify sector-specific targeted campaigns as they’re emerging, allows customers to benefit from threat intelligence collected from others in their same line of business. The federal government has a wide range of private sector business partners across healthcare, finance, critical infrastructure, and agriculture, to name a few. Each of these partners extends the government attack surface beyond the government-controlled boundary, and each represents an opportunity for compromise.
Imagine a scenario where an HHS healthcare partner is alerted, in real-time across a public/private sector threat intelligence sharing grid, to a threat affecting either the federal government directly or a healthcare partner for a different government agency. This approach allows them to assess their own environment for attack indicators, make quick informed decisions about defensive changes, and limit access where necessary. This type of real-time alerting not only allows the HHS partner to better prepare for a threat, but ultimately serves to reduce the attack surface of the federal government.
Allowing industry partners to develop and participate in building out cyber threat telemetry enables:
The U.S. government can begin to effectively shift focus from a reactive culture to one that is more proactive, enabling faster action against threats (or something like this). In the next EO, the Administration should bulk up its commitment to sharing cyber threat information with the private sector. The capability to exchange cyber threat intelligence data across the industry in standards-based formats in near real time exists today. The collective “we” just needs to make it a priority.
The post White House Executive Order – Removing Barriers to Sharing Threat Information appeared first on McAfee Blogs.
This blog was written by Vallabh Chole & Oliver Devane
Over the years, the cybersecurity industry has seen many threats get taken down, such as the Emotet takedown in January 2021. It doesn’t usually take long for another threat to attempt to fill the gap left by the takedown. Hancitor is one such threat.
Like Emotet, Hancitor can send Malspams to spread itself and infect as many users as possible. Hancitor’s main purpose is to distribute other malware such as FickerStealer, Pony, CobaltStrike, Cuba Ransomware and Zeppelin Ransomware. The dropped Cobalt Strike beacons can then be used to move laterally around the infected environment and also execute other malware such as ransomware.
This blog will focus on a new technique used by Hancitor created to prevent crawlers from accessing malicious documents used to download and execute the Hancitor payload.
The infection flow of Hancitor is shown below:
A victim will receive an email with a fake DocuSign template to entice them to click a link. This link leads him to feedproxy.google.com, a service that works similar to an RSS Feed and enables site owners to publish site updates to its users.
When accessing the link, the victim is redirected to the malicious site. The site will check the User-Agent of the browser and if it is a non-Windows User-Agent the victim will be redirected to google.com.
If the victim is on a windows machine, the malicious site will create a cookie using JavaScript and then reload the site.
The code to create the cookie is shown below:
The above code will write the Timezone to value ‘n’ and the time offset to UTC in value ‘d’ and set it into cookie header for an HTTP GET Request.
For example, if this code is executed on a machine with timezone set as BST the values would be:
d = 60
n = “Europe/London”
These values may be used to prevent further malicious activity or deploy a different payload depending on geo location.
Upon reloading, the site will check if the cookie is present and if it is, it will present them with the malicious document.
A WireShark capture of the malicious document which includes the cookie values is shown below:
The document will prompt them to enable macros and, when enabled, it will download the Hancitor DLL and then load it with Rundll32.
Hancitor will then communicate with its C&C and deploy further payloads. If running on a Windows domain, it will download and deploy a Cobalt Strike beacon.
Hancitor will also deploy SendSafe which is a spam module, and this will be used to send out malicious spam emails to infect more victims.
With its ability to send malicious spam emails and deploy Cobalt Strike beacons, we believe that Hancitor will be a threat closely linked to future ransomware attacks much like Emotet was. This threat also highlights the importance of constantly monitoring the threat landscape so that we can react quickly to evolving threats and protect our customers from them.
IOCs
| IOC | Type | IOC | Coverage | Content Version |
| Malicious Document | SHA256 | e389a71dc450ab4077f5a23a8f798b89e4be65373d2958b0b0b517de43d06e3b | W97M/Dropper.hx
|
4641 |
| Hancitor DLL | SHA256 | c703924acdb199914cb585f5ecc6b18426b1a730f67d0f2606afbd38f8132ad6
|
Trojan-Hancitor.a | 4644 |
| Domain hosting Malicious Document | URL | http[:]//onyx-food[.]com/coccus.php | RED | N/A |
| Domain hosting Malicious Document
|
URL | http[:]//feedproxy[.]google[.]com/~r/ugyxcjt/~3/4gu1Lcmj09U/coccus.php | RED | N/A |
Mitre
| Technique ID | Tactic | Technique details |
| T1566.002 | Initial Access | Spam mail with links |
| T1204.001 | Execution | User Execution by opening link. |
| T1204.002 | Execution | Executing downloaded doc |
| T1218 | Defence Evasion | Signed Binary Execution Rundll32 |
| T1055 | Defence Evasion | Downloaded binaries are injected into svchost for execution |
| T1482 | Discovery | Domain Trust Discovery |
| T1071 | C&C | HTTP protocol for communication |
| T1132 | C&C | Data is base64 encoded and xored |
The post Hancitor Making Use of Cookies to Prevent URL Scraping appeared first on McAfee Blogs.
This blog was written by Kiran Raj & Kishan N.
In the last few years, Microsoft Office macro malware using social engineering as a means for malware infection has been a dominant part of the threat landscape. Malware authors continue to evolve their techniques to evade detection. These techniques involve utilizing macro obfuscation, DDE, living off the land tools (LOLBAS), and even utilizing legacy supported XLS formats.
McAfee Labs has discovered a new technique that downloads and executes malicious DLLs (Zloader) without any malicious code present in the initial spammed attachment macro. The objective of this blog is to cover the technical aspect of the newly observed technique.
Infection map
The section below contains the detailed technical analysis of this technique.
The malware arrives through a phishing email containing a Microsoft Word document as an attachment. When the document is opened and macros are enabled, the Word document, in turn, downloads and opens another password-protected Microsoft Excel document.
After downloading the XLS file, the Word VBA reads the cell contents from XLS and creates a new macro for the same XLS file and writes the cell contents to XLS VBA macros as functions.
Once the macros are written and ready, the Word document sets the policy in the registry to Disable Excel Macro Warning and invokes the malicious macro function from the Excel file. The Excel file now downloads the Zloader payload. The Zloader payload is then executed using rundll32.exe.
Figure-1: flowchart of the Infection chain
Here is how the face of the document looks when we open the document (figure 2). Normally, the macros are disabled to run by default by Microsoft Office. The malware authors are aware of this and hence present a lure image to trick the victims guiding them into enabling the macros.
Figure-2: Image of Word Document Face
The userform combo-box components present in the Word document stores all the content required to connect to the remote Excel document including the Excel object, URL, and the password required to open the Excel document. The URL is stored in the Combobox in the form of broken strings which will be later concatenated to form a complete clear string.
Figure-3: URL components (right side) and the password to open downloaded Excel document (“i5x0wbqe81s”) present in user-form components.
Figure-4: Image of the VBA editor
In the above image of macros (figure 4), the code is attempting to download and open the Excel file stored in the malicious domain. Firstly, it creates an Excel application object by using CreateObject() function and reading the string from Combobox-1 (ref figure-2) of Userform-1 which has the string “excel. Application” stored in it. After creating the object, it uses the same object to open the Excel file directly from the malicious URL along with the password without saving the file on the disk by using Workbooks.Open() function.
Figure-5: Word Macro code that reads strings present in random cells in Excel sheet.
The above snippet (figure 5) shows part of the macro code that is reading the strings from the Excel cells.
For Example:
Ixbq = ifk.sheets(3).Cells(44,42).Value
The code is storing the string present in sheet number 3 and the cell location (44,42) into the variable “ixbq”. The Excel.Application object that is assigned to variable “ifk” is used to access sheets and cells from the Excel file that is opened from the malicious domain.
In the below snippet (figure 6), we can observe the strings stored in the variables after being read from the cells. We can observe that it has string related to the registry entry “HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security\AccessVBOM” that is used to disable trust access for VBA into Excel and the string “Auto_Open3” that is going to be the entry point of the Excel macro execution.
We can also see the strings “ThisWorkbook”, “REG_DWORD”, “Version”, “ActiveVBProject” and few random functions as well like “Function c4r40() c4r40=1 End Function”. These macro codes cannot be detected using static detection since the content is formed dynamically on run time.
Figure-6: Value of variables after reading Excel cells.
After extracting the contents from the Excel cells, the parent Word file creates a new VBA module in the downloaded Excel file by writing the retrieved contents. Basically, the parent Word document is retrieving the cell contents and writing them to XLS macros.
Once the macro is formed and ready, it modifies the below RegKey to disable trust access for VBA on the victim machine to execute the function seamlessly without any Microsoft Office Warnings.
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security\AccessVBOM
After writing macro contents to Excel file and disabling the trust access, function ’Auto_Open3()’ from newly written excel VBA will be called which downloads zloader dll from the ‘hxxp://heavenlygem.com/22.php?5PH8Z’ with extension .cpl
Figure-7: Image of ’Auto_Open3()’ function
The downloaded dll is saved in %temp% folder and executed by invoking rundll32.exe.
Figure-8: Image of zloader dll invoked by rundll32.exe
Rundll32.exe shell32.dll,Control_RunDLL “<path downloaded dll>”
Windows Rundll32 commands loads and runs 32-bit DLLs that can be used for directly invoking specified functions or used to create shortcuts. In the above command line, the malware uses “Rundll32.exe shell32.dll,Control_RunDLL” function to invoke control.exe (control panel) and passes the DLL path as a parameter, therefore the downloaded DLL is executed by control.exe.
The below image (figure 9) is the face of the password-protected Excel file that is hosted on the server. We can observe random cells storing chunks of strings like “RegDelete”, “ThisWorkbook”, “DeleteLines”, etc.
These strings present in worksheet cells are formed as VBA macro in the later stage.
Figure-9: Image of Remote Excel file.
McAfee’s Endpoint products detect this variant of malware and files dropped during the infection process.
The main malicious document with SHA256 (210f12d1282e90aadb532e7e891cbe4f089ef4f3ec0568dc459fb5d546c95eaf) is detected with V3 package version – 4328.0 as “W97M/Downloader.djx”. The final Zloader payload with SHA-256 (c55a25514c0d860980e5f13b138ae846b36a783a0fdb52041e3a8c6a22c6f5e2)which is a DLL is detected by signature “Zloader-FCVP” with V3 package version – 4327.0
Additionally, with the help of McAfee’s Expert rule feature, customers can strengthen the security by adding custom Expert rules based on the behavior patterns of the malware. The below EP rule is specific to this infection pattern.
McAfee advises all users to avoid opening any email attachments or clicking any links present in the mail without verifying the identity of the sender. Always disable the macro execution for Office files. We advise everyone to read our blog on this new variant of Zloader and its infection cycle to understand more about the threat.
Different techniques & tactics are used by the malware to propagate and we mapped these with the MITRE ATT&CK platform.
| Type | Value | Scanner | Detection Name | Detection Package Version (V3) |
| Main Word Document | 210f12d1282e90aadb532e7e891cbe4f089ef4f3ec0568dc459fb5d546c95eaf | ENS | W97M/Downloader.djx | 4328 |
| Downloaded dll | c55a25514c0d860980e5f13b138ae846b36a783a0fdb52041e3a8c6a22c6f5e2 | ENS | Zloader-FCVP | 4327 |
| URL to download XLS | hxxp://heavenlygem.com/11.php | WebAdvisor
|
Blocked | N/A |
| URL to download dll | hxxp://heavenlygem.com/22.php?5PH8Z | WebAdvisor
|
Blocked | N/A |
Malicious documents have been an entry point for most malware families and these attacks have been evolving their infection techniques and obfuscation, not just limiting to direct downloads of payload from VBA, but creating agents dynamically to download payload as we discussed in this blog. Usage of such agents in the infection chain is not only limited to Word or Excel, but further threats may use other living off the land tools to download its payloads.
Due to security concerns, macros are disabled by default in Microsoft Office applications. We suggest it is safe to enable them only when the document received is from a trusted source.
The post Zloader With a New Infection Technique appeared first on McAfee Blogs.
Ryuk is a ransomware that encrypts a victim’s files and requests payment in Bitcoin cryptocurrency to release the keys used for encryption. Ryuk is used exclusively in targeted ransomware attacks.
Ryuk was first observed in August 2018 during a campaign that targeted several enterprises. Analysis of the initial versions of the ransomware revealed similarities and shared source code with the Hermes ransomware. Hermes ransomware is a commodity malware for sale on underground forums and has been used by multiple threat actors.
To encrypt files Ryuk utilizes a combination of symmetric AES (256-bit) encryption and asymmetric RSA (2048-bit or 4096-bit) encryption. The symmetric key is used to encrypt the file contents, while the asymmetric public key is used to encrypt the symmetric key. Upon payment of the ransom the corresponding asymmetric private key is released, allowing the encrypted files to be decrypted.
Because of the targeted nature of Ryuk infections, the initial infection vectors are tailored to the victim. Often seen initial vectors are spear-phishing emails, exploitation of compromised credentials to remote access systems and the use of previous commodity malware infections. As an example of the latter, the combination of Emotet and TrickBot, have frequently been observed in Ryuk attacks.
Ryuk is detected as Ransom-Ryuk![partial-hash].
Defenders should be on the lookout for traces and behaviours that correlate to open source pen test tools such as winPEAS, Lazagne, Bloodhound and Sharp Hound, or hacking frameworks like Cobalt Strike, Metasploit, Empire or Covenant, as well as abnormal behavior of non-malicious tools that have a dual use. These seemingly legitimate tools (e.g., ADfind, PSExec, PowerShell, etc.) can be used for things like enumeration and execution. Subsequently, be on the lookout for abnormal usage of Windows Management Instrumentation WMIC (T1047). We advise everyone to check out the following blogs on evidence indicators for a targeted ransomware attack (Part1, Part2).
When it comes to the actual ransomware binary, we strongly advise updating and upgrading endpoint protection, as well as enabling options like tamper protection and Rollback. Please read our blog on how to best configure ENS 10.7 to protect against ransomware for more details.
Ryuk ransomware is used exclusively in targeted attacks
Latest sample now targets webservers
New ransom note prompts victims to install Tor browser to facilitate contact with the actors
After file encryption, the ransomware will print 50 copies of the ransom note on the default printer
Learn more about Ryuk ransomware, including Indicators of Compromise, Mitre ATT&CK techniques and Yara Rule, by reading our detailed technical analysis.
The post New Ryuk Ransomware Sample Targets Webservers appeared first on McAfee Blogs.
ImageMagick is a hugely popular open source software that is used in lot of systems around the world. It is available for the Windows, Linux, MacOS platforms as well as Android and iOS. It is used for editing, creating or converting various digital image formats and supports various formats like PNG, JPEG, WEBP, TIFF, HEIC and PDF, among others.
Google OSS Fuzz and other threat researchers have made ImageMagick the frequent focus of fuzzing, an extremely popular technique used by security researchers to discover potential zero-day vulnerabilities in open, as well as closed source software. This research has resulted in various vulnerability discoveries that must be addressed on a regular basis by its maintainers. Despite the efforts of many to expose such vulnerabilities, recent fuzzing research from McAfee has exposed new vulnerabilities involving processing of multiple image formats, in various open source and closed source software and libraries including ImageMagick and Windows GDI+.
Fuzzing open source libraries has been covered in a detailed blog “Vulnerability Discovery in Open Source Libraries Part 1: Tools of the Trade” last year. Fuzzing ImageMagick is very well documented, so we will be quickly covering the process in this blog post and will focus on the root cause analysis of the issue we have found.
ImageMagick has lot of configuration options which we can see by running following command:
| $./configure –help |
We can customize various parameters as per our needs. To compile and install ImageMagick with AFL for our case, we can use following commands:
|
$CC=afl-gcc CXX=afl=g++ CFLAGS=”-ggdb -O0 -fsanitize=address,undefined -fno-omit-frame-pointer” LDFLAGS=”-ggdb -fsanitize=address,undefined -fno-omit-frame-pointer” ./configure
$ make -j$(nproc) $sudo make install |
This will compile and install ImageMagick with AFL instrumentation. The binary we will be fuzzing is “magick”, also known as “magick tool”. It has various options, but we will be using its image conversion feature to convert our image from one format to another.
A simple command would be include the following:
| $ magick <input file> <output file> |
This command will convert an input file to an output file format. We will be fuzzing this with AFL.
Before we start fuzzing, we need to have a good input corpus. One way of collecting corpus is to search on Google or GitHub. We can also use existing test corpus from various software. A good test corpus is available on the AFL site here: https://lcamtuf.coredump.cx/afl/demo/
Corpus collection is one thing, but we also need to minimize the corpus. The way AFL works is that it will instrument each basic block so that it can trace the program execution path. It maintains a shared memory as a bitmap and it uses an algorithm to check new block hits. If a new block hit has been found, it will save this information to bitmap.
Now it may be possible that more than one input file from the corpus can trigger the same path, as we have collected sample files from various sources, we don’t have any information on what paths they will trigger at the runtime. If we use this corpus without removing such files, then we end up wasting time and CPU cycles. We need to avoid that.
Interestingly AFL offers a utility called “afl-cmin” which we can use to minimize our test corpus. This is a recommended thing to do before you start any fuzzing campaign. We can run this as follows:
| $afl-cmin -i <input directory> -o <output directory> — magick @@ /dev/null |
This command will minimize the input corpus and will keep only those files which trigger unique paths.
After we have minimized corpus, we can start fuzzing. To fuzz we need to use following command:
| $afl-fuzz -i <mincorpus directory> -o <output directory> — magick @@ /dev/null |
This will only run a single instance of AFL utilizing a single core. In case we have multicore processors, we can run multiple instances of AFL, with one Master and n number of Slaves. Where n is the available CPU cores.
To check available CPU cores, we can use this command:
| $nproc |
This will give us the number of CPU cores (depending on the system) as follows:
In this case there are eight cores. So, we can run one Master and up to seven Slaves.
To run master instances, we can use following command:
| $afl-fuzz -M Master -i <mincorpus directory> -o <output directory> — magick @@ /dev/null |
We can run slave instances using following command:
|
$afl-fuzz -S Slave1 -i <mincorpus directory> -o <output directory> — magick @@ /dev/null
$afl-fuzz -S Slave2 -i <mincorpus directory> -o <output directory> — magick @@ /dev/null |
The same can be done for each slave. We just need to use an argument -S and can use any name like slave1, slave2, etc.
Within a few hours of beginning this Fuzzing campaign, we found one crash related to an out of bound read inside a heap memory. We have reported this issue to ImageMagick, and they were very prompt in fixing it with a patch the very next day. ImageMagick has release a new build with version: 7.0.46 to fix this issue. This issue was assigned CVE-2020-27829.
On checking the POC file, we found that it was a TIFF file.
When we open this file with ImageMagick with following command:
| $magick poc.tif /dev/null |
As a result, we see a crash like below:
As is clear from the above log, the program was trying to read 1 byte past allocated heap buffer and therefore ASAN caused this crash. This can atleast lead to a ImageMagick crash on the systems running vulnerable version of ImageMagick.
Before we start debugging this issue to find a root cause, it is necessary to understand the TIFF file format. Its specification is very well described here: http://paulbourke.net/dataformats/tiff/tiff_summary.pdf.
In short, a TIFF file has three parts:
We can tiffinfo utility from libtiff to gather various information about the POC file. This allows us to see the following information with tiffinfo like width, height, sample per pixel, row per strip etc.:
There are a few things to note here:
| TIFF Dir offset is: 0xa0
Image width is: 3 and length is: 32 Bits per sample is: 9 Sample per pixel is: 3 Rows per strip is: 1024 Planer configuration is: single image plane. We will be using this data moving forward in this post. |
As we can see in the crash log, program was crashing at function “PushQuantumPixel” in the following location in quantum-import.c line 256:
On checking “PushQuantumPixel” function in “MagickCore/quantum-import.c” we can see the following code at line #256 where program is crashing:
We can see following:
The program is crashing at this location while reading the value of “pixels” which means that value is out of bound from the allocated heap memory.
Now we need to figure out following:
To start with, we can check “ReadTIFFImage” function in coders/tiff.c file and see that it allocates memory using a “AcquireQuantumMemory” function call, which appears as per the documentation mentioned here:
https://imagemagick.org/api/memory.php:
“Returns a pointer to a block of memory at least count * quantum bytes suitably aligned for any use.
The format of the “AcquireQuantumMemory” method is:
void *AcquireQuantumMemory(const size_t count,const size_t quantum)
A description of each parameter follows:
count
the number of objects to allocate contiguously.
quantum
the size (in bytes) of each object. “
In this case two parameters passed to this function are “extent” and “sizeof(*strip_pixels)”
We can see that “extent” is calculated as following in the code below:
There is a function TIFFStripSize(tiff) which returns size for a strip of data as mentioned in libtiff documentation here:
http://www.libtiff.org/man/TIFFstrip.3t.html
In our case, it returns 224 and we can also see that in the code mentioned above, “image->columns * sizeof(uint64)” is also added to extent, which results in 24 added to extent, so extent value becomes 248.
So, this extent value of 248 and sizeof(*strip_pixels) which is 1 is passed to “AcquireQuantumMemory” function and total memory of 248 bytes get allocated.
This is how memory is allocated.
“Strip_pixel” is pointer to newly allocated memory.
Note that this is 248 bytes of newly allocated memory. Since we are using ASAN, each byte will contain “0xbe” which is default for newly allocated memory by ASAN:
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/asan/asan_flags.inc
The memory start location is 0x6110000002c0 and the end location is 0x6110000003b7, which is 248 bytes total.
This memory is set to 0 by a “memset” call and this is assigned to a variable “p”, as mentioned in below image. Please also note that “p” will be used as a pointer to traverse this memory location going forward in the program:
Later on we see that there is a call to “TIFFReadEncodedPixels” which reads strip data from TIFF file and stores it into newly allocated buffer “strip_pixels” of 248 bytes (documentation here: http://www.libtiff.org/man/TIFFReadEncodedStrip.3t.html):
To understand what this TIFF file data is, we need to again refer to TIFF file structure. We can see that there is a tag called “StripOffsets” and its value is 8, which specifies the offset of strip data inside TIFF file:
We see the following when we check data at offset 8 in the TIFF file:
We see the following when we print the data in “strip_pixels” (note that it is in little endian format):
So “strip_pixels” is the actual data from the TIFF file from offset 8. This will be traversed through pointer “p”.
Inside “ReadTIFFImage” function there are two nested for loops.
Here “stride” is calculated by calling function “TIFFVStripSize()” function which as per documentation returns the number of bytes in a strip with nrows rows of data. In this case it is 14. So, every time pointer “p” is incremented by “14” or “0xE” inside the second for loop.
If we print the image structure which is passed to “ImportQuantumPixels” function as parameter, we can see following:
Here we can notice that the columns value is 3, the rows value is 32 and depth is 9. If we check in the POC TIFF file, this has been taken from ImageWidth and ImageLength and BitsPerSample value:
Ultimately, control reaches to “ImportRGBQuantum” and then to the “PushQuantumPixel” function and one of the arguments to this function is the pixels data which is pointed by “p”. Remember that this points to the memory address which was previously allocated using the “AcquireQuantumMemory” function, and that its length is 248 byte and every time value of “p” is increased by 14.
The “PushQuantumPixel” function is used to read pixel data from “p” into the internal pixel data storage of ImageMagick. There is a for loop which is responsible for reading data from the provided pixels array of 248 bytes into a structure “quantum_Info”. This loop reads data from pixels incrementally and saves it in the “quantum_info->state.pixels” field.
The root cause here is that there are no proper bounds checks and the program tries to read data beyond the allocated buffer size on the heap, while reading the strip data inside a for loop.
This causes a crash in ImageMagick as we can see below:
Therefore, to summarize, the program crashes because:
If we check at the patch diff, we can see that the following changes were made to fix this issue:
Here the 2nd argument to “AcquireQuantumMemory” is multiplied by 2 thus increasing the total amount of memory and preventing this Out of Bound read issue from heap memory. The total memory allocated is 496 bytes, 248*2=496 bytes, as we can see below:
A new version of ImageMagick 7.0.46 was released to fix this issue. While the patch fixes the memory allocation issue, if we check the code below, we can see that there was a call to memset which didn’t set the proper memory size to zero.
Memory was allocated extent*2*sizeof(*strip_pixels) but in this memset to 0 was only done for extent*sizeof(*strip_pixels). This means half of the memory was set to 0 and rest contained 0xbebebebe, which is by default for ASAN new memory allocation.
This has since been fixed in subsequent releases of ImageMagick by using extent=2*TIFFStripSize(tiff); in the following patch:
Processing various image files requires deep understanding of various file formats and thus it is possible that something may not be exactly implemented or missed. This can lead to various vulnerabilities in such image processing software. Some of this vulnerability can lead to DoS and some can lead to remote code execution affecting every installation of such popular software.
Fuzzing plays an important role in finding vulnerabilities often missed by developers and during testing. We at McAfee constantly fuzz various closed source as well as open source software to help secure them. We work very closely with various vendors and do responsible disclosure. This shows McAfee’s commitment towards securing the software and protecting our customers from various threats.
We will continue to fuzz various software and work with vendors to help mitigate risk arriving from such threats.
We would like to thank and appreciate ImageMagick team for quickly resolving this issue within 24 hours and releasing a new version to fix this issue.
The post Fuzzing ImageMagick and Digging Deeper into CVE-2020-27829 appeared first on McAfee Blogs.
This post was written by Emmanuel
Making the most of opportunities and putting in the work with an employer who invests in you is a powerful combination. My journey at McAfee would not be complete had it not been for the chance to prove myself.
McAfee Rotation Program (MRP) program helps candidates find the right fit within the organization. MRP consists of five-month-long placements within Professional Services, Pre-Sales Engineering, Security Operations, and Sales Operations. To be accepted, candidates must complete and score well during three rigorous days of evaluation.
There is no promise you’ll be hired, only the promise that McAfee will give you every chance to prove your worth. And when you succeed, the benefits are far greater than just a paycheck.
In 2018, about a year after earning my Bachelor’s Degree in Mechanical Engineering and Mathematics, I learned about the program while looking for work. Even though cybersecurity wasn’t my background, I decided to take a chance.
McAfee flew me from my home in New Jersey to Dallas to complete an intensive course consisting of 10- to 12-hour days of interviews, presentations, logic tests, and team-building exercises. One of the toughest parts was presenting on McAfee products, something I knew very little about, and having only a few hours overnight to prepare once given the assignment.
Those days were extremely challenging and tested me in ways that I didn’t think possible. Even though it wasn’t really tailored to my area of studies, the program was an opportunity to work for one of the largest global corporations. I was resolved to stay focused and make an impression.
And I was hungry. Failing wasn’t an option. I had done my research and wanted the opportunity to work for McAfee.
About two weeks after the course, McAfee informed me that I was one of six candidates to be accepted into the MRP. The journey to help me find the best position soon began.
For the next two years, I worked five rotations or positions within the program’s designated areas. It wasn’t long before I began charting my path to what interested me most.
Last year, I achieved my goal of becoming an Enterprise Security Engineer.
I could not have achieved success without God, the help of a lot of people, and a diverse culture that embraces personal and professional growth.
McAfee gives you the opportunity to not just find what you do best but fulfill your passions. Along the way, you are recognized and mentored – a great achievement was receiving the “Who’s Doing This” award based on performance within my first year at McAfee.
The company invests in you personally and professionally, not just through training opportunities, but by encouraging healthy lifestyles and work-life balance. When we’re not working remotely, every Friday employees can bring their dogs to work through the Pups at Work Program. Some people have actually become attached to their coworkers’ pets!
Building connections has helped launch my career, understand where I want to go and how to get there. Like any new hire, you have to develop into your role, and that is only made possible with the right direction and encouragement. Coworkers and leadership have continually helped me along my journey.
Even through a period of remote working, McAfee has developed an online culture which makes you feel as though everybody is collaborating in person.
And the learning never stops. My mentor spends time each month guiding me down my career path, which is a huge plus.
What I like about McAfee is you are given every chance to succeed, which instills a strong work ethic and the ability to give back. I was fortunate to help lead another MRP soon after completing my rotation. Leadership entrusted me to coordinate the program from start to finish, and it was rewarding to watch the development of those who succeeded.
My time here has been sweet, and I could not pick a better company to launch my career. I’ve gone from somebody with no background in information technology and security to being a subject matter expert.
Those three days in Dallas were tough, but sometimes you have to put in a little sweat equity to reach your goal. They are among the greatest days of my career and make working for McAfee that much sweeter.
Are you thinking about joining our team? McAfee takes great pride in providing candidates every opportunity to show their true value. Learn more about our jobs. Subscribe to job alerts.
The post How I Seized McAfee’s Opportunities to Realize My Potential appeared first on McAfee Blogs.
Microsoft Windows Graphics Device Interface+, also known as GDI+, allows various applications to use different graphics functionality on video displays as well as printers. Windows applications don’t directly access graphics hardware such as device drivers, but they interact with GDI, which in turn then interacts with device drivers. In this way, there is an abstraction layer to Windows applications and a common set of APIs for everyone to use.
Because of its complex format, GDI+ has a known history of various vulnerabilities. We at McAfee continuously fuzz various open source and closed source software including windows GDI+. Over the last few years, we have reported various issues to Microsoft in various Windows components including GDI+ and have received CVEs for them.
In this post, we detail our root cause analysis of one such vulnerability which we found using WinAFL: CVE-2021-1665 – GDI+ Remote Code Execution Vulnerability. This issue was fixed in January 2021 as part of a Microsoft Patch.
WinAFL is a Windows port of a popular Linux AFL fuzzer and is maintained by Ivan Fratric of Google Project Zero. WinAFL uses dynamic binary instrumentation using DynamoRIO and it requires a program called as a harness. A harness is nothing but a simple program which calls the APIs we want to fuzz.
A simple harness for this was already provided with WinAFL, we can enable “Image->GetThumbnailImage” code which was commented by default in the code. Following is the harness code to fuzz GDI+ image and GetThumbnailImage API:
As you can see, this small piece of code simply creates a new image object from the provided input file and then calls another function to generate a thumbnail image. This makes for an excellent attack vector and can affect various Windows applications if they use thumbnail images. In addition, this requires little user interaction, thus software which uses GDI+ and calls GetThumbnailImage API, is vulnerable.
A good corpus provides a sound foundation for fuzzing. For that we can use Google or GitHub in addition to further test corpus available from various software and public EMF files which were released for other vulnerabilities. We have generated a few test files by making changes to a sample code provided on Microsoft’s site which generates an EMF file with EMFPlusDrawString and other records:
After we have collected an initial corpus file, we need to minimize it. For this we can use a utility called winafl-cmin.py as follows:
| winafl-cmin.py -D D:\\work\\winafl\\DynamoRIO\\bin32 -t 10000 -i inCorpus -o minCorpus -covtype edge -coverage_module gdiplus.dll -target_module gdiplus_hardik.exe -target_method fuzzMe -nargs 2 — gdiplus_hardik.exe @@ |
WinAFL uses the concept of in-memory fuzzing. We need to provide a function name to WinAFL. It will save the program state at the start of the function and take one input file from the corpus, mutate it, and feed it to the function.
It will monitor this for any new code paths or crashes. If it finds a new code path, it will consider the new file as an interesting test case and will add it to the queue for further mutation. If it finds any crashes, it will save the crashing file in crashes folder.
The following picture shows the fuzzing flow:
Once we have compiled our harness program, collected, and minimized the corpus, we can run this command to fuzz our program with WinAFL:
| afl-fuzz.exe -i minCorpus -o out -D D:\work\winafl\DynamoRIO\bin32 -t 20000 —coverage_module gdiplus.dll -fuzz_iterations 5000 -target_module gdiplus_hardik.exe -target_offset 0x16e0 -nargs 2 — gdiplus_hardik.exe @@ |
We found a few crashes and after triaging unique crashes, and we found a crash in “gdiplus!BuiltLine::GetBaselineOffset” which looks as follows in the call stack below:
As can be seen in the above image, the program is crashing while trying to read data from a memory address pointed by edx+8. We can see it registers ebx, ecx and edx contains c0c0c0c0 which means that page heap is enabled for the binary. We can also see that c0c0c0c0 is being passed as a parameter to “gdiplus!FullTextImager::RenderLine” function.
To figure out a root cause, we can use patch diffing—namely, we can use IDA BinDiff plugin to identify what changes have been made to patched file. If we are lucky, we can easily find the root cause by just looking at the code that was changed. So, we can generate an IDB file of patched and unpatched versions of gdiplus.dll and then run IDA BinDiff plugin to see the changes.
We can see that one new function was added in the patched file, and this seems to be a destructor for BuiltLine Object :
We can also see that there are a few functions where the similarity score is < 1 and one such function is FullTextImager::BuildAllLines as shown below:
Now, just to confirm if this function is really the one which was patched, we can run our test program and POC in windbg and set a break point on this function. We can see that the breakpoint is hit and the program doesn’t crash anymore:
Now, as a next step, we need to identify what has been changed in this function to fix this vulnerability. For that we can check flow graph of this function and we see something as follows. Unfortunately, there are too many changes to identify the vulnerability by simply looking at the diff:
The left side illustrates an unpatched dll while right side shows a patched dll:
If we zoom in on the yellow blocks we can see following:
We can note several changes. Few blocks are removed in the patched DLL, so patch diffing will alone will not be sufficient to identify the root cause of this issue. However, this presents valuable hints about where to look and what to look for when using other methods for debugging such as windbg. A few observations we can spot from the bindiff output above:
So we can assume that this is where the vulnerability is fixed. Now we need to figure out following:
EMF is also known as enhanced meta file format which is used to store graphical images device independently. An EMF file is consisting of various records which is of variable length. It can contain definition of various graphic object, commands for drawing and other graphics properties.
Credit: MS EMF documentation.
Generally, an EMF file consist of the following records:
Detailed specifications of EMF file format can be seen at Microsoft site at following URL:
Generally, most of the issues in EMF are because of malformed or corrupt records. We need to figure out which record type is causing this crash. For this if we look at the call stack we can see following:
We can notice a call to function “gdiplus!GdipPlayMetafileRecordCallback”
By setting a breakpoint on this function and checking parameter, we can see following:
We can see that EDX contains some memory address and we can see that parameter given to this function are: 00x00401c,0x00000000 and 0x00000044.
Also, on checking the location pointed by EDX we can see following:
If we check our POC EMF file, we can see that this data belongs to file from offset: 0x15c:
By going through EMF specification and manually parsing the records, we can easily figure out that this is a “EmfPlusDrawString” record, the format of which is shown below:
In our case:
Record Type = 0x401c EmfPlusDrawString record
Flags = 0x0000
Size = 0x50
Data size = 0x44
Brushid = 0x02
Format id = 0x01
Length = 0x14
Layoutrect = 00 00 00 00 00 00 00 00 FC FF C7 42 00 00 80 FF
String data =
Now that we have located the record that seems to be causing the crash, the next thing is to figure out why our program is crashing. If we debug and check the code, we can see that control reaches to a function “gdiplus!FullTextImager::BuildAllLines”. When we decompile this code, we can see something like this:
The following diagram shows the function call hierarchy:
1. Inside “Builtline::BuildAllLines” memory will be allocated for 0x60 or 96 bytes, and in the debugger it looks as follows:
2. Then it calls “BuiltLine::BuiltLine” function and moves the data to newly allocated memory:
3. This happens in side a while loop and there is a function call to “BuiltLine::GetUntrimmedCharacterCount”.
4. Return value of “BuiltLine::GetUntrimmedCharacterCount” is stored in a location 0x12ff2ec. This value will be 1 as can be seen below:
5. This value gets added to ECX:
6. Then there is a check that determines if ecx< eax. If true, it will continue loop, else it will jump to another location:
7. Now in the vulnerable version, loop doesn’t exist if the return value of “BuiltLine::GetUntrimmedCharacterCount” is 0, which means that this 0 will be added to ECX and which means ECX will not increase. So the loop will execute 1 more time with the “ECX” value of 0x13. Thus, this will lead to loop getting executed 21 times rather than 20 times. This is the root cause of the problem here.
Also after some debugging, we can figure out why EAX contains 14. It is read from the POC file at offset: 0x174:
If we recall, this is the EmfPlusDrawString record and 0x14 is the length we mentioned before.
Later on, the program reaches to “FullTextImager::Render” function corrupting the value of EAX because it reads the unused memory:
This will be passed as an argument to “FullTextImager::RenderLine” function:
Later, program will crash while trying to access this location.
Our program was crashing while processing EmfPlusDrawString record inside the EMF file while accessing an invalid memory location and processing string data field. Basically, the program was not verifying the return value of “gdiplus!BuiltLine::GetUntrimmedCharacterCount” function and this resulted in taking a different program path that corrupted the register and various memory values, ultimately causing the crash.
As we have figured out by looking at patch diff above, a check was added which determined the return value of “gdiplus!BuiltLine::GetUntrimmedCharacterCount” function.
If the retuned value is 0, then program xor’s EBX which contains counter and jump to a location which calls destructor for Builtline Object:
Here is the destructor that prevents the issue:
GDI+ is a very commonly used Windows component, and a vulnerability like this can affect billions of systems across the globe. We recommend our users to apply proper updates and keep their Windows deployment current.
We at McAfee are continuously fuzzing various open source and closed source library and work with vendors to fix such issues by responsibly disclosing such issues to them giving them proper time to fix the issue and release updates as needed.
We are thankful to Microsoft for working with us on fixing this issue and releasing an update.
The post Analyzing CVE-2021-1665 – Remote Code Execution Vulnerability in Windows GDI+ appeared first on McAfee Blogs.
The McAfee Advanced Threat Research team today published the McAfee Labs Threats Report: June 2021.
In this edition we introduce additional context into the biggest stories dominating the year thus far including recent ransomware attacks. While the topic itself is not new, there is no question that the threat is now truly mainstream.
This Threats Report provides a deep dive into ransomware, in particular DarkSide, which resulted in an agenda item in talks between U.S. President Biden and Russian President Putin. While we have no intention of detailing the political landscape, we certainly do have to acknowledge that this is a threat disrupting our critical services. Furthermore, adversaries are supported within an environment that make digital investigations challenging with legal barriers that make the gathering of digital evidence almost impossible from certain geographies.
That being said, we can assure the reader that all of the recent campaigns are incorporated into our products, and of course can be tracked within our MVISION Insights preview dashboard.
This dashboard shows that – beyond the headlines – many more countries have experienced such attacks. What it will not show is that victims are paying the ransoms, and criminals are introducing more Ransomware-as-a-Service (RaaS) schemes as a result. With the five-year anniversary of the launch of the No More Ransom initiative now upon us it’s fair to say that we need more global initiatives to help combat this threat.
McAfee Labs threat research during the first quarter of 2021 include:
Additional Q1 2021 content includes:
We hope you enjoy this Threats Report. Don’t forget to keep track of the latest campaigns and continuing threat coverage by visiting our McAfee Threat Center. Please stay safe.
The post McAfee Labs Report Highlights Ransomware Threats appeared first on McAfee Blogs.
How much of the global economy is managed from a home network these days? Or, more importantly, what percentage of your company’s most sensitive data passes through employee home networks right now?
If you’re like me, working from a home office, you can’t help but think about all of the cybersecurity tradeoffs that accompanied the widespread shift from on-premises to cloud-delivered services. Better productivity in exchange for deeper vulnerabilities—like man-in-the-middle attacks—wasn’t a choice many cybersecurity pros would make under normal circumstances.
Yet, for better—and worse—there’s no going back to how things were. When Gartner revealed its annual list of top cybersecurity trends last month, we learned that while 64% of employees now work from home, at least 30-40% will continue to do so once the pandemic is over.1 In the foreseeable future, the Wi-Fi streaming your kids’ favorite shows will transport an untold amount of business data, too. All of which must be protected from device to cloud.
In the same report, Gartner said that with so many employees continuing to work from home, “endpoint protection services will need to move to cloud-delivered services.” While the vast majority of our customers made the overnight switch—many still need to adopt a cloud-native architecture.
No doubt the best transformations are the ones you plan for and manage from end-to-end. But the cloud transformation that many didn’t plan for—and most cybersecurity defenses couldn’t handle—turned out to pack the biggest punch. Here are three ways to better prepare for what comes next.
Stopping unauthorized access to corporate assets—and protecting them—is, on the face of it, a never-ending battle. You can’t build a moat, a wall, or a bubble and say, hey, my work here is done. We’ve found our customers need to solve two primary issues:
So, we created the MVISION Device-to-Cloud Suites to protect all of this data coursing through home networks. Among the many types of threats we’ve tracked, one of the biggest threats is viruses infecting browsers and capturing keystrokes to steal sensitive information. We solve this by isolating a browser so that no one can see what information has been entered.
While paradigms may shift, going forward we believe it’s predictive defenses that will enable faster, smarter and more effective data loss prevention. We get there by enabling optimized endpoint threat protection, Extended Detection and Response (EDRs) that improve mean time to detect and respond to threats, and useful analytics that not only empower your SOC but also help inform and engage executives.
Gaining executive and board-level buy-in has long been a topic of concern in the cybersecurity field. Thanks in part to the harsh publicity and severe damage caused by state-sponsored hacks that day is finally in sight. In a recent blog, McAfee’s Steve Grobman indicated SolarWinds is the first major supply chain attack which represents a shift in tactics where a nation state has employed a new weapon for cyber-espionage.”2
Cybersecurity is perceived as the second highest source of risk for enterprises, losing out to regulatory concerns, notes Gartner.3 While today only one in 10 board of directors have a dedicated cybersecurity committee, Gartner projects that percentage will rise to 40% in four years.
One reason why cybersecurity hasn’t been elevated to an ongoing board concern previously is that many executives lack a window into the cybersecurity in their midst. And lacking a window, they have no keen understanding of their organization’s vulnerabilities. Which also makes it difficult to assess the operational value of various cybersecurity investments.
The ability to gain visual insights and predictive assessments of your security posture against dangerous threats is what generates actionable intelligence. A CISO or CSO should be able to look at a single screen and understand in minutes how well protected they are against potential threats. They also need a team that’s ready to take action on these insights and enact appropriate countermeasures to protect corporate assets from imminent attack.
You want to protect your palace from thieves, but when do you finally have too many latches, locks, and bars on your doors? At some point, less is more, particularly if you can’t remember where you put your keys. Consolidation is one of Gartner top five trends this year. Four out of five companies plan to trim their list of cybersecurity vendors in the next three years.4
In fact, Gartner’s 2020 CISO Effectiveness Survey found that 78% of CISOs have 16 or more tools in their cybersecurity vendor portfolio, while 12% have a whopping 46 or more.5 Mind you, we know there is no end-all, be-all Security vendor who does everything. But with our Device-to-Cloud Suites, your security technology resides in one umbrella platform. Without McAfee, you’d need one vendor on the desktop, another in the cloud, and one more on the web gateway.
Consolidation is intended to remove headaches rather than create them. With one SaaS-based suite that addresses your core security issues, you have lower maintenance, plus the ability to visualize where you’re vulnerable and learn what you need to do to protect it.
McAfee is here to help organizations manage the transformation to a predictive cybersecurity defense and we provide the footprint to secure the data, endpoints, web, and cloud. From my vantage point, securing distributed digital assets demands effective security controls from device to cloud.
MVISION Device-to-Cloud Suites provide a simplified way to help accelerate your cloud transformation and adoption, better defend against attacks, and lower your total cost of operations. The suites scale with your security needs to deliver a unified endpoint, web, and cloud solution.
Learn More About McAfee Device-to-Cloud Suites:
Source:
1. Gartner Identifies Top Security and Risk Management Trends for 2021 (Gartner)
2. Why SolarWinds-SUNBURST is a Wakeup Call (McAfee)
3. Gartner Identifies Top Security and Risk Management Trends for 2021 (Gartner)
4. Ibid.
5. Gartner Survey Reveals Only 12% of CISOs Are Considered “Highly Effective” (Gartner)
The post Transforming to a Predictive Cyber Defense appeared first on McAfee Blogs.
The McAfee Advanced Threat Research team (ATR) is committed to uncovering security issues in both software and hardware to help developers provide safer products for businesses and consumers. As security researchers, something that we always try to establish before looking at a target is what our scope should be. More specifically, we often assume well-vetted technologies like network stacks or the OS layers are sound and instead focus our attention on the application layers or software that is specific to a target. Whether that approach is comprehensive sometimes doesn’t matter; and it’s what we decided to do for this project as well, bypassing the Android OS itself and with a focus on the Peloton code and implementations. During our research process, we uncovered a flaw (CVE-2021-33887) in the Android Verified Boot (AVB) process, which was initially out of scope, that left the Peloton vulnerable.
For those that are not familiar with Peloton, it is a brand that has combined high end exercise equipment with cutting-edge technology. Its products are equipped with a large tablet that interfaces with the components of the fitness machine, as well as provides a way to attend virtual workout classes over the internet. “Under the hood” of this glossy exterior, however, is a standard Android tablet, and this hi-tech approach to exercise equipment has not gone unnoticed. Viral marketing mishaps aside, Peloton has garnered attention recently regarding concerns surrounding the privacy and security of its products. So, we decided to take a look for ourselves and purchased a Pelton Bike+.
One of the first things that we usually try do when starting a new project, especially when said projects involve large expenses like the Peloton, is to try to find a way to take a backup or a system dump that could be used if a recovery is ever needed. Not all of our research techniques keep the device in a pristine state (we’d be poor hackers if they did), and having the ability to restore the device to its factory settings is a safety net that we try to implement on our targets.
Because we are working with a normal Android device with only the Peloton customizations running at the application layer, many of the processes used to back up an Android phone would also work with the Peloton. It is common in the Android custom ROM scene to use a custom recovery image that allows the user to take full flash dumps of each critical partition and provides a method to restore them later. In such communities, it often also goes without saying that the device must first be unlocked in order to perform any of these steps. While the Android OS allows users to flash these critical partitions, there are restrictions in place that typically prevent an attacker from gaining access to the “currently” running system. If an attacker was able to get their hands on an Android device with the goal of installing a rootkit, they would have to jump through some hoops. The first step that an attacker would need to take is to enable “Original Equipment Manufacturer (OEM) Unlocking”, which is a user mode setting within the “developer options” menu. Even with physical access to the bootloader, an attacker would not be able to “unlock” the Android device unless this setting is checked. This option is usually secured behind the user’s password, PIN, or biometric phone lock, preventing an attacker from accessing it easily. The second security measure in place is that even with the “OEM Unlocking” setting on, issuing commands to the bootloader to perform the unlock first causes all data on the Android device, including applications, files, passwords, etc., to be wiped. This way, even if an attacker did gain access to the Android device of an unsuspecting victim, they wouldn’t be able to install a rootkit or modify the existing kernel without deleting all the data, which both prevents personal data from falling into the attacker’s hands and makes it obvious the device has been tampered with.
For this research effort, we resisted the urge to unlock the Peloton, as there are ways for apps to query the unlock status of a device within Android, and we wanted to ensure that any vulnerabilities we found weren’t the result of the device behaving differently due to it being unlocked. These discrepancies that arise from our research are usually identified by having two target devices: one to serve as the control and the other to serve as the test device. Unfortunately, we only had one Peloton to play with. Another issue was that the Peloton hardware is not very common and the developers of the aforementioned custom recovery images, like Team Win Recovery Project (TWRP), don’t create images for every device, just the most common ones. So, the easy method of taking a backup would not only require unlocking the device but also trying to create our own custom recovery image.
This left us as at a crossroads. We could unlock the bootloader and root the device, granting us access to the flash memory block devices (raw interfaces to the flash partitions) internally, which would allow us to create and restore backups as needed. However, as mentioned before, this would leave the bike in a recognizably “tampered” state. Alternatively, we could try to capture one of the bike’s Over-The-Air (OTA) updates to use as a backup, but we would still need to “unlock” the device to actually flash the OTA image manually. Both options were less than ideal so we kept looking for other solutions.
Just as Secure Boot provides a security mechanism for properly booting the OS on Windows PCs, Android has implemented measures to control the boot process, called Android Verified Boot (AVB). According to Android’s documentation, AVB “requires cryptographically verifying all executable code and data that is part of the Android version being booted before it is used. This includes the kernel (loaded from the boot partition), the device tree (loaded from the dtbo partition), system partition, vendor partition, and so on.”
The Peloton Bike+ ships with the default settings of “Verity Mode” set to true, as well as “Device Unlocked” and “Device Critical Unlocked” set to false, which is intended to prevent the loading of modified boot images and provide a way to determine if the device has been tampered with. This information was verified by running fastboot oem device-info on the Peloton, as demonstrated in Figure 1.
Figure 1: OEM device info showing verity mode and unlocked status.
To clarify, a simplified Android boot process can be visualized as follows:
Figure 2: Simplified Android Boot Process
If modified code is found at any of the stages in Figure 2, the boot process should abort or, if the device is unlocked, warn the user that the images are not verified and give the option to the user to abort the boot.
Given that we defined our scope of this project to not include the Android boot process as a part of our research and verifying that Peloton has attempted to use the security measures provided by Android, we again found ourselves debating if a backup would be possible.
In newer Android releases, including the Peloton, the update method uses Android’s Seamless System Updates (A/B). This update method no longer needs the “recovery” partition, forcing users who wish to use a custom recovery to use the fastboot boot command which will download and boot the supplied image. This is a temporary boot that doesn’t “flash“ or alter any of the flash partitions of the device and will revert to the previous boot image on restart. Since this option allows for modified code to be executed, it is only available when the device is in an unlocked state and will error out with a message stating “Please unlock device to enable this command,” if attempted on a locked device.
This is a good security implementation because if this command was always allowed, it would be very similar to the process of booting from a live USB on your PC, where you can login as a root user and have full control over the underlying system and components.
This is where our luck or maybe naïveté worked to our advantage. Driven by our reluctance to unlock the device and our desire to make a backup, we tried to boot a generic TWRP recovery image just to see what would happen. The image ended up leaving us at a black screen, and since each recovery image needs to contain a small kernel with the correct drivers for the display, touch digitizer, and other device–specific hardware, this was to be expected. What we didn’t expect, however, was for it to get past the fastboot boot command. While we didn’t get a custom recovery running, it did tell us one thing; the system was not verifying that the device was unlocked before attempting to boot a custom image. Normally this command would be denied on a “locked” device and would have just errored out on the fastboot command, as mentioned previously.
It is also important to point out that despite having booted a modified image, the internal fuse had not been burned. These fuses are usually burned during the OEM unlocking process to identify if a device has allowed for a different “root of trust” to be installed. The burning of such a fuse is a permanent operation and a burnt fuse often indicates that the device has been tampered with. As shown in Figure 3, the “Secure Boot” fuse was still present, and the device was reporting a locked bootloader.
Figure 3: Secure boot enabled with fused protection
This discovery was unexpected and we felt like we had stumbled upon a flaw that gave us the ability to finally take a backup of the device and leave the Peloton in an “untampered” state. Knowing that a custom image could be booted even with a “locked” bootloader, we began looking at ways to gather a valid boot image, which would contain the correct kernel drivers to facilitate a successful boot. If we could piece together the OTA update URL and just download an update package directly from Peloton, it would likely contain a boot image that we could modify. Having the ability to modify a boot image would give us root and access to the blocked devices.
Even with just ADB debugging enabled we were able to pull the Peloton–specific applications from the device. We listed all the Peloton APKs and sought out the ones that could help us get the OTA path, shown in Figure 4.
Figure 4: Listing Peloton Specific Applications and Highlighting the one related to OTA Updates.
Finding the name OTAService promising, we pulled down the APK and began to reverse-engineer it using JADX. After some digging, we discovered how the app was building the download URL string for OTA updates, which would then be passed to beginDownload(), as seen in Figure 5.
Figure 5: OTA image path being constructed as “key”
We also noticed quite a few Android log calls that could help us, such as the one right before the call to beginDownload(), so we used Android’s built–in logcat command and grepped the output for “OTA” as seen in Figure 6. Doing so, we were able to find which S3 bucket was used for the OTA updates and even a file manifest titled OTAConfig.json.
Figure 6: Relevant OTA logs in red
Combining the information obtained from OTAService.apk and the logs, we were able to piece together the full path to the OTA images manifest file and names for each OTA zip file, as shown in Figure 7.
Figure 7: Contents of OTAConfig.json
Our next step was to extract the contents of the OTA update to get a valid boot.img file that would contain all the specific kernel drivers for the Peloton hardware. Since the Peloton is using Android’s A/B partitions, which facilitate seamless updates, the update packages were stored in a “payload.bin” format. Using the Android payload dumper tool, we were able to extract all of the images contained in the bin file.
Once the boot.img was extracted, we needed a way to modify the initial kernel to allow us to gain root access on the device. Although there are a variety of ways to accomplish this, we decided to keep things simple and just use the Magisk installer to patch the boot.img file to include the “su” binary. With the boot.img patched, we were able to use the fastboot boot command again but this time passing it our patched boot.img file. Since the Verified Boot process on the Peloton failed to identify the modified boot image as tampered, the OS booted normally with the patched boot.img file. After this process was complete, the Peloton Bike+ was indistinguishable from its “normal” state under visual inspection and the process left no artifacts that would tip off the user that the Pelton had been compromised. But appearances can be deceiving, and in reality the Android OS had now been rooted, allowing us to use the “su” command to become root and perform actions with UID=0, as seen in Figure 8.
Figure 8: Booting modified boot.img and executing whoami as Root
As we just demonstrated, the ability to bypass the Android Verified Boot process can lead to the Android OS being compromised by an attacker with physical access. A worst-case scenario for such an attack vector might involve a malicious agent booting the Peloton with a modified image to gain elevated privileges and then leveraging those privileges to establish a reverse shell, granting the attacker unfettered root access on the bike remotely. Since the attacker never has to unlock the device to boot a modified image, there would be no trace of any access they achieved on the device. This sort of attack could be effectively delivered via the supply chain process. A malicious actor could tamper with the product at any point from construction to warehouse to delivery, installing a backdoor into the Android tablet without any way the end user could know. Another scenario could be that an attacker could simply walk up to one of these devices that is installed in a gym or a fitness room and perform the same attack, gaining root access on these devices for later use. The Pelobuddy interactive map in figure 9 below could help an attacker find public bikes to attack.
Figure 9: pelobuddy.com’s interactive map to help locate public Peloton exercise equipment.
Once an attacker has root, they could make their presence permanent by modifying the OS in a rootkit fashion, removing any need for the attacker to repeat this step. Another risk is that an attacker could modify the system to put themselves in a man-in-the-middle position and sniff all network traffic, even SSL encrypted traffic, using a technique called SSL unpinning, which requires root privileges to hook calls to internal encryption functionality. Intercepting and decrypting network traffic in this fashion could lead to users’ personal data being compromised. Lastly, the Peloton Bike+ also has a camera and a microphone installed. Having remote access with root permissions on the Android tablet would allow an attacker to monitor these devices and is demoed in the impact video below.
Given the simplicity and criticality of the flaw, we decided to disclose to Peloton even as we continue to audit the device for remote vulnerabilities. We sent our vendor disclosure with full details on March 2, 2021 – shortly after, Peloton confirmed the issue and subsequently released a fix for it in software version “PTX14A-290”. The patched image no longer allows for the “boot” command to work on a user build, mitigating this vulnerability entirely. The Peloton vulnerability disclosure process was smooth, and the team were receptive and responsive with all communications. Further conversations with Peloton confirmed that this vulnerability is also present on Peloton Tread exercise equipment; however, the scope of our research was confined to the Bike+.
Peloton’s Head of Global Information Security, Adrian Stone, shared the following “this vulnerability reported by McAfee would require direct, physical access to a Peloton Bike+ or Tread. Like with any connected device in the home, if an attacker is able to gain physical access to it, additional physical controls and safeguards become increasingly important. To keep our Members safe, we acted quickly and in coordination with McAfee. We pushed a mandatory update in early June and every device with the update installed is protected from this issue.”
We are continuing to investigate the Peloton Bike+, so make sure you stay up to date on McAfee’s ATR blogs for any future discoveries.
The post A New Program for Your Peloton – Whether You Like It or Not appeared first on McAfee Blogs.
The McAfee team is very proud to announce that, for the third year in a row, McAfee was named a 2021 Gartner Peer Insights Customers’ Choice for Secure Web Gateways for its Web Solution.
In its announcement, Gartner explains, “The Gartner Peer Insights Customers’ Choice is a recognition of vendors in this market by verified end-user professionals, taking into account both the number of reviews and the overall user ratings.” To ensure fair evaluation, Gartner applies rigorous methodology for recognizing vendors with a high customer satisfaction rate.
For the distinction, a vendor needs at least 20+ Reviews from Customers with over $50M Annual Review in 18-month timeframe, above Market Average Overall Rating, and above Market Average User Interest and Adoption.
Gartner Peer Insights is a peer review and ratings platform designed for enterprise software and services decision makers. Reviews are organized by products in markets that are defined by Gartner Research in Magic Quadrant and Market Guide documents.
The “Voice of the Customer” is a document that applies a methodology to aggregated Gartner Peer Insights’ reviews in a market to provide an overall perspective for IT decision makers. This aggregated peer perspective, along with the individual detailed reviews, is complementary to expert-generated research such as Magic Quadrants and Market Guides. It can play a key role in your buying process, as it focuses on direct peer experiences of buying, implementing and operating a solution. A complimentary copy of the Peer Insights ‘Voice of the Customer’ report is available on the McAfee Web site.
“We were using an on-prem web gateway and we have been migrated to UCE recently due to the pandemic situations. It gives us the flexibility to manage our Web GW as a SaaS solution. The solution also provides us bunch of rulesets for our daily usage needs.” CIO in the Manufacturing Industry [Link here]
“McAfee Secure web gateway provides the optimum security required for the employees of the Bank surfing the Internet. It also provides the Hybrid capabilities which allows to deploy same policies regardless of the physical location of the endpoint.” [Link here]
MVISION Unified Cloud Edge was specifically designed to enable our customers to make a secure cloud transformation by bringing the capabilities of our highly successful Secure Web Gateway appliance solution to the cloud as part of a unified cloud offering. This way, users from any location or device can access the web and the cloud in a fast and secure manner.
“The McAfee Web Gateway integrated well with existing CASB and DLP solutions. It has been very effective at preventing users from going to malware sites. The professional services we purchased for implementation was the best we’ve ever had from any vendor of any IT security product.” Senior Cybersecurity Professional in the Healthcare Industry [Link here]
McAfee’s Next-Gen Secure Web Gateway technology features tight integration with our CASB and DLP solutions through a converged management interface, which provides unified policies that deliver unprecedented cloud control while reducing cost and complexity. By integrating our SWG, CASB, DLP, and RBI solutions, MVISION Unified Cloud Edge provides a complete SASE security platform that delivers unparalleled data and threat protection.
“We benchmarked against another very well known gateway and there was no comparison. The other gateway only caught a small fraction of what MWG caught when filtering for potentially harmful sites.” Information Security Officer in the Finance Industry [Link here]
As the threat landscape continues to evolve, it’s important for organizations to have a platform that is integrated and seamless. That’s why McAfee provides integrated multi-layer security including global threat intelligence, machine learning, sandboxing, UEBA, and Remote Browser Isolation to block known threats and detect the most elusive attacks.
To learn more about this distinction, or to read the reviews written about our products by the IT professionals who use them, please visit Gartner Peer Insights’ Customers’ Choice announcement for Web. To all of our customers who submitted reviews, thank you! These reviews mold our products and our customer journey, and we look forward to building on the experience that earned us this distinction!
McAfee is named a Customers’ Choice in the June 2021 Gartner Peer Insights “Voice of the Customer”: Secure Web Gateways.
The post McAfee Named a 2021 Gartner Peer Insights Customers’ Choice for SWG appeared first on McAfee Blogs.
The mass migration of employees working from home in the last 14 months has accelerated the digital transformation of businesses. Cloud applications are no longer a “nice to have,” they are now essential to ensure that businesses survive. This introduces new security challenges in being able to locate and control sensitive data across all the potential exfiltration vectors regardless of whether they are in the cloud; on premise via managed or unmanaged machines. Attempting to control these vectors through multiple products results in unnecessary cost and complexity.
McAfee anticipated and responded to this trend, solving all these challenges through the launch of our MVISION Unified Cloud Edge solution in 2020. Unified Cloud Edge doesn’t simply offer data protections controls for endpoints, networks, web and the cloud; rather, Multi-Vector Data Protection provides customers with unified data classification and incident management that enables them to define data workflows once and have policies enforced consistently across each vector. Because of the unified approach and our extensive data protection heritage, we are delighted to be named a Leader in The Forrester Wave: Unstructured Data Security Platforms, Q2 2021. In our opinion, we were the top ranked dedicated cyber security vendor within the report.
We received the highest possible score in nine criteria with Forrester Research commenting on our “cloud-first data security approach” and customer recognition of our “breadth of capabilities (in particular for supporting remote work and cloud use)”.
We continue to innovate within our Unified Cloud Edge solution through the introduction of remote browser isolation to protect against risky web sites (our “heavy focus in supporting security and data protection in the cloud”), which uniquely to the market allows us to continue applying DLP controls even during isolated sessions. Delivering on increased customer value through innovation isn’t just limited to new features, for instance we continue to drive down costs through an unlimited SaaS application bundle.
Click below to read the full report.
: Unstructured Data Security Platforms, Q2 2021McAfee is delighted to be named a Leader in The Forrester Wave Unstructured Data Security Platforms, Q2 2021 report. We received the highest possible score in nine criteria with Forrester Research
The Forrester Wave: Unstructured Data Security Platforms, Q2 2021, 17 May 2021, Heidi Shey with Amy DeMartine, Shannon Fish, Peggy Dostie
The post McAfee a Leader in The Forrester Wave™ Unstructured Data Security Platforms appeared first on McAfee Blogs.
On May 12, the President signed the executive order (EO) on Improving the Nation’s Cybersecurity. As with every executive order, it establishes timelines for compliance and specific requirements of executive branch agencies to provide specific plans to meet the stated objectives.
It is clear from the EO that the Executive Office of the President is putting significant emphasis on cyber threat intelligence and how it will help government agencies make better decisions about responding to cyber threats and incidents. The EO also focuses on how federal agencies will govern resource access through Zero Trust and how to comprehensively define and protect hybrid service architectures. These are critical aspects as government agencies are moving more and more mission-critical applications and services to the cloud.
The call to action in this executive order is long overdue, as modernizing the nation’s cybersecurity approach and creating coordinated intelligence and incident response capabilities should have occurred years ago. Requiring that agencies recognize the shift in the perimeter and start tearing down silos between cloud services and physical data center services is going serve to improve visibility and understanding of how departments and sub-agencies are being targeted by adversaries.
I am sure government leaders have started to review their current capability along with their strategic initiatives to ensure they map to the new EO requirements. Where gaps are identified, agencies will need to update their plans and rethink their approach to align with the new framework and defined capabilities such as endpoint detection and response (EDR) and Zero Trust.
While the objectives outlined are critical, I do believe that agencies need to take appropriate cautions when deciding their paths to compliance. The goal of this executive order is not to add additional complexity to an already complex security organization. Rather, the goal should be to simplify and automate wherever possible. If the right approach is not decided on early, the risk is very real of adding too much complexity in pursuit of compliance, thus eroding the desired outcomes.
On the surface, it would seem that the areas of improvement outlined in the EO can be taken individually – applied threat intelligence, EDR, Zero Trust, data protection, and cloud services adoption. In reality, they should be viewed collectively. When considering solutions and architectures, agency leaders should be asking themselves some critical questions:
The executive order presents a great opportunity for government to evolve their cybersecurity approach to defend against modern threats and enable a more aggressive transition to the cloud and cloud services. There is also significant risk, as the urgency expressed in the EO could lead to hasty decisions that create more challenges than they solve. To capitalize on the opportunity presented in this executive order, federal leaders must embrace a holistic approach to cybersecurity that integrates all the solutions into a platform approach including robust threat intelligence. A standalone Zero Trust or EDR product will not accomplish an improved or modernized cybersecurity approach and could lead to more complexity. A well-thought-out platform, not individual products, will best serve public sector organizations, giving them a clear architecture that will protect and enable our government’s future.
The post The Executive Order – Improving the Nation’s Cyber Security appeared first on McAfee Blogs.
Virtualization technology has been an IT cornerstone for organization for years now. It revolutionized the way organizations can scale up IT systems in a heartbeat, allowing then to be more agile as opposed to investing into dedicated “bare-metal” hardware. To the outside untrained eye, it might seem that there are different machines on the network, while in fact all the “separate” machines are controlled by a hypervisor server. Virtualization plays such a big role nowadays that it isn’t only used to spin up servers but also anything from virtual applications to virtual user desktops.
This is something cyber criminals have been noticing too and we have seen an increased interest in hypervisors. After all, why attack the single virtual machine when you can go after the hypervisor and control all the machines at once?
In recent months several high impact CVEs regarding virtualization software have been released which allowed for Remote Code Execution (RCE); initial access brokers are offering compromised VMware vCenter servers online, as well as ransomware groups developing specific ransomware binaries for encrypting ESXi servers.
On the 25th of May VMware disclosed a vulnerability impacting VMware vCenter servers allowing for Remote Code Execution on internet accessible vCenter servers, version 6.5,6.7 and 7.0. VMware vCenter is a management tool, used to manage virtual machines and ESXi servers.
CVE-2021-21985 is a remote code execution (RCE) vulnerability in the vSphere Client via the Virtual SAN (vSAN) Health Check plugin. This plugin is enabled by default. The combination of RCE and default enablement of the plugin resulted in this being scored as a critical flaw with a CVSSv3 score of 9.8.
An attacker needs to be able to access vCenter over TCP port 443 to exploit this vulnerability. It doesn’t matter if the vCenter is remotely exposed or when the attacker has internal access.
The same exploit vector is applicable for CVE-2021-21986, which is an authentication mechanism issue in several vCenter Server Plug-ins. It would allow an attacker to run plugin functions without authentication. This leads to the CVE being scored as a ‘moderate severity’, with a CVSSv3 score of 6.5.
While writing this blog, a Proof-of-Concept was discovered that will test if the vulnerability exists; it will not execute the remote-code. The Nmap plugin can be downloaded from this location: https://github.com/alt3kx/CVE-2021-21985_PoC.
Searching with the Shodan search engine, narrowing it down to the TCP 443 port, we observe that close to 82,000 internet accessible ESXi servers are exposed. Zooming in further on the versions that are affected by these vulnerabilities, almost 55,000 publicly accessible ESXi servers are potentially vulnerable to CVE-2021-21985 and CVE-2021-21986, providing remote access to them and making them potential candidates for ransomware attacks, as we will read about in the next paragraphs.
Ransomware groups are always trying to find ways to hit their victims where it hurts. So, it is only logical that they are adapting to attacking virtualization environments and the native Unix/Linux machines running the hypervisors. In the past, ransomware groups were quick to abuse earlier CVEs affecting VMware. But aside from the disclosed CVEs, ransomware groups have also adapted their binaries specifically to encrypt virtual machines and their management environment. Below are some of the ransomware groups we have observed.
Figure 1. Screenshot from the DarkSide ransomware group, explicitly mentioning its Linux-based encryptor and support for ESXi and NAS systems
McAfee Advanced Threat Research (ATR) analyzed the DarkSide Linux binary in our recent blog and we can confirm that a specific routine aimed at virtual machines is present in it.
Figure 2. DarkSide VMware Code routine
From the configuration file of the DarkSide Linux variant, it becomes clear that this variant is solely designed to encrypt virtual machines hosted on an ESXi server. It searches for the disk-files of the VMs, the memory files of the VMs (vmem), swap, logs, etc. – all files that are needed to start a VMware virtual machine.
Demo of Darkside encrypting an ESXi server: https://youtu.be/SMWIckvLMoE
Babuk announced on an underground forum that it was developing a cross-platform binary aimed at Linux/UNIX and ESXi or VMware systems:
Figure 3. Babuk ransomware claiming to have built a Linux-based ransomware binary capable of encrypting ESXi servers
The malware is written in the open-source programming language Golang, most likely because it allows developers to have a single codebase to be compiled into all major operating systems. This means that, thanks to static linking, code written in Golang on a Linux system can run on a Windows or Mac system. That presents a large advantage to ransomware gangs looking to encrypt a whole infrastructure comprised of different systems architecture.
After being dropped on the ESXi server, the malware encrypts all the files on the system:
The malware was designed to target ESXi environments as we guessed, and it was confirmed when the Babuk team returned the decryptor named d_esxi.out. Unfortunately, the decryptor has been developed with some errors, which cause corruption in victim’s files:
Overall, the decryptor is poor as it only checks for the extension “.babyk” which will miss any files the victim has renamed to recover them. Also, the decryptor checks if the file is more than 32 bytes in length as the last 32 bytes are the key that will be calculated later with other hardcoded values to get the final key. This is bad design as those 32 bytes could be trash, instead of the key, as the customer could make things, etc. It does not operate efficiently by checking the paths that are checked in the malware, instead it analyzes everything. Another error we noticed was that the decryptor tries to remove a ransom note name that is NOT the same that the malware creates in each folder. This does not make any sense unless, perhaps, the Babuk developers/operators are delivering a decryptor that works for a different version and/or sample.
The problems with the Babuk decryptor left victims in horrible situations with permanently damaged data. The probability of getting a faulty decryptor isn’t persuading victims to pay up and this might be one of the main reasons that Babuk announced that it will stop encrypting data and only exfiltrate and extort from now on.
It is not only ransomware groups that show an interest in virtual systems; several initial access brokers are also trading access to compromised vCenter/ESXi servers on underground cybercriminal forums. The date and time of the specific offering below overlaps with the disclosure of CVE-2021-21985, but McAfee ATR hasn’t determined if this specific CVE was used to gain access to ESXi servers.
Figure 4. Threat Actor selling access to thousands of vCenter/ESXi servers
Figure 5. Threat actor offering compromised VMware ESXi servers
VMware urges users running VMware vCenter and VMware Cloud Foundation affected by CVE-2021-21985 and CVE-2021-21986 to apply its patch immediately. According to VMware, a malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server. The disclosed vulnerabilities have a critical CVSS base score of 9.8.
However, we do understand that VMware infrastructure is often installed on business-critical systems, so any type of patching activity usually has a high degree of impact on IT operations. Hence, the gap between vulnerability disclosure and patching is typically high. With the operating systems on VMware being a closed system they lack the ability to natively install workload protection/detection solutions. Therefore, the defenses should be based on standard cyber hygiene/risk mitigation practices and should be applied in the following order where possible.
Virtualization and its underlying technologies are key in today’s infrastructures. With the release of recently discovered vulnerabilities and an understanding of their criticality, threat actors are shifting focus. Proof can be seen in underground forums where affiliates recruit pentesters with knowledge of specific virtual technologies to develop custom ransomware that is designed to cripple these technologies. Remote Desktop access is the number one access vector in many ransomware cases, followed by edge-devices lacking the latest security updates, making them vulnerable to exploitation. With the latest VMware CVEs mentioned in this blog, we urge you to take the right steps to secure not only internet exposed systems, but also internal systems, to minimize the risk of your organization losing its precious VMs, or gold, to cyber criminals.
Special thanks to Thibault Seret, Mo Cashman, Roy Arnab and Christiaan Beek for their contributions.
The post Are Virtual Machines the New Gold for Cyber Criminals? appeared first on McAfee Blogs.
May 2021 has been an extraordinary month in the cybersecurity world, with the DoD releasing its DoD Zero Trust Reference Architecture (DoDZTRA), the Colonial Pipeline being hit with a ransomware attack, and the White House releasing its Executive Order on Improving the Nation’s Cybersecurity (EO). Add to that several major vendors that our government depends on for its critical operations disclosing critical vulnerabilities that could potentially expose our nation’s critical infrastructure to even more risk, ranging from compromised email and cloud infrastructures to very sophisticated supply chain attacks like the SolarWinds hack, which could have started as early as 2019.
If the situation sounds ominous, it is. The words and guidance outlined in the DoDZTRA and EO must be followed up with a clear path to action and all the stakeholders, both public and private, are not held accountable for progress. This should not be another roll-up reporting exercise, time to study the situation, or end up in analysis paralysis thinking about the problem. Our adversaries move at speeds we never anticipated by leveraging automation, artificial intelligence, machine learning, social engineering, and more vectors against us. It’s time for us to catch up and just very possibly think differently to get ahead.
There is no way around it: This time our nation must invest in protecting our way of life today and for future generations.
The collective “we” observed what happened when ransomware hit a portion of the nation’s critical infrastructure at Colonial Pipeline. If the extortion wasn’t bad enough, the panic buying of gasoline and even groceries in many of Eastern U.S. states impacted thousands of people seemingly overnight, with help from social and traditional media. It’s too early to predict what the exact financial and social impacts may have been on this attack. I suspect the $4.4M ransom paid was very small in the greater scheme of the event.
May 2021 has provided a wake-up call for public-private cooperation like we’ve never seen before. Perhaps we need to rethink cybersecurity altogether. During his keynote remarks at the recent RSA Conference, McAfee CTO Steve Grobman talked about how “as humans, we are awful at perceiving risk.” Influenced by media, anecdotal data, and evolutionary biology, we let irrational fears drive decision-making, which leads humans to misperceive actual risks and sub-optimize risk reduction in both the physical and cyber world. To combat these tendencies, Steve encourages us to “be aware of our biases and embrace data and science-based approaches to assess and mitigate risk.”
Enter Zero Trust Cybersecurity, which is an architectural approach – not a single vendor product or solution. The DoDZTRA takes a broader view of Zero Trust than the very narrow access control focus, saying it is “a cybersecurity strategy and framework that embeds security throughout the architecture to prevent malicious personas from accessing our most critical assets.” And our most critical assets are data.
NSA also recently weighed in on Zero Trust, recommending that an organization invest in identifying its critical data, assets, applications, and services. The NSA guidance goes on to suggest placing additional focus on architecting from the inside out; ensuring all paths to data, assets, applications, and services are secure; determining who needs access; creating control policies; and finally, inspecting and logging all traffic before reacting.
These practices require full visibility into all activity across all layers — from endpoints to the network (which includes cloud) — to enable analytics that can detect suspicious activity. The ability to have early or advanced warnings of global and local threat campaigns, indicators of compromise, and the capability to deliver proactive countermeasures is a must-have as part of an organization’s defensive strategies.
The Zero Trust guidance from both DoD and NSA is worth following. It’s also worth reprising the concept of defense in depth – the cybersecurity strategy of leveraging multiple security mechanisms to protect an organization’s assets. Relying on a single vendor for all an organization’s IT and security needs makes it much easier for the adversary.
If you believe in a good conspiracy theory, the month of May 2021 could provide great material for a made-for-TV movie. Earlier I mentioned that the collective “we” needs to be held accountable. Part of that accountability is defining success metrics as we take on a new path to real cybersecurity.
The post Why May 2021 Represents a New Chapter in the “Book of Cybersecurity Secrets” appeared first on McAfee Blogs.
Browser push notifications can highly resemble Windows system notifications. As recently discussed, scammers are abusing push notifications to trick users into taking action. This recent example demonstrates the social engineering tactics used to trick users into installing a fake Windows Defender update. A toaster popup in the tray informs the user of a Windows Defender Update.
Clicking the message takes the user to a fake update website.
The site serves a signed ms-appinstaller (MSIX) package. When downloaded and run, the user is prompted to install a supposed Defender Update from “Publisher: Microsoft”
After installation, the “Defender Update” App appears in the start menu like other Windows Apps.
The shortcut points to the installed malware: C:\Program Files\WindowsApps\245d1cf3-25fc-4ce1-9a58-7cd13f94923a_1.0.0.0_neutral__7afzw0tp1da5e\bloom\Eversible.exe, which is a data stealing trojan, targeting various applications and information:
The post Scammers Impersonating Windows Defender to Push Malicious Windows Apps appeared first on McAfee Blogs.
Every year CRN recognizes the women who are leading the channel and their unique strengths, vision, and achievements. This year, CRN recognized five McAfee individuals on their prestigious list of those leading the channel. Those selected demonstrate commitment to mentoring future generations and driving channel innovation and growth.
The 2021 Women of the Channel (WOTC) awards highlight over 1,000 women in all areas of the IT ecosystem, including technology vendors, distributors, solution providers and other IT organizations. We’re thrilled to see our colleagues recognized for their strategic vision and dedication to channel success. See below to learn more about each McAfee honoree.
Please join us in celebrating this recognition and congratulating these exceptional women who are at the heart of our channel business.
A channel veteran of 20+ years and 2020 WOTC recipient, Kristin Carnes joined McAfee through the acquisition of Skyhigh Networks and has lead channel growth for industry bellwethers like EMC (NYSE: EMC), Nimble Storage, (HPE Subsidiary) and Veritas Software. She was chosen to lead McAfee’s global channel programs and operations and now leads global teams supporting an extensive network of distributors. Kristin was instrumental in organizing the early 2021 expansion of McAfee and Ingram Micro’s partnership to sell in more than 20 countries leveraging the Ingram Cloud Marketplace. She has also launched new partner experience initiatives that have been adopted worldwide and driven changes in the McAfee rebate policy to improve partner profitability.
Madeline Fugate is an experienced sales and marketing leader with 23 years of experience in the channel. Madeline has a passion for mentoring and nurturing younger talent. Through coaching, she has developed a strong McAfee team for Tech Data that has delivered Tech Data’s Cyber Range with McAfee on premise and cloud solutions as well as an easy to use customer demo environment. Her work with Tech Data led to further growth in 2021 with IBM. This year, she also launched McAfee’s first social media campaign through Tech Data and played a fundamental role in improving operational efficiency to reduce quoting lead times.
With 25+ years of experience in distribution, Sheri Leach has dedicated the last 15 years to supporting and growing Ingram Micro with their McAfee business. This year, she was instrumental in launching McAfee on the Ingram Micro Cloud Marketplace soon to bring in millions of dollars in no touch business to McAfee and our partners. She’s worked closely with the team at Ingram Micro to also facilitate a creative finance program and to deliver a Business Intelligence program that helped the McAfee sales teams to create, plan and execute on business plans to drive more sales. Sheri was recognized on the 2020 WOTC list and believes that in 2021, the keys to partner success are partner enablement, frequent engagement and special finance to ensure partners are thriving amid the pandemic.
Sarah Thompson joined McAfee’s channel organization 13 years ago and has spent the last six years focused on building the Service Provider Specialization for partners delivering managed services globally. This year, Sarah managed the launch coordination, tracking progress and initiatives across product, channel, marketing and executive teams for McAfee’s partner lead managed endpoint detection and response (EDR) offerings. She’s driven innovation for McAfee’s channel by helping define a select set of partners as Global Service Provider Partners through the creation of formal requirements and curriculum.
Natalie Tomlin has been at McAfee for over 20 years, and currently drives much of McAfee’s “Channel First” global strategy through resources, tools, enablement and marketing efforts ensuring partners and customers have a good experience with McAfee. Her team is focused on helping McAfee’s strategic partners lead customer cloud adoption and deliver security from Device to Cloud. Returning to the WOTC list from 2020, Natalie’s current goal is to continue with McAfee’s “Channel First” strategy and to continue empowering, enabling, and listen to our partners.
The post CRN’s Women of the Channel 2021 Recognizes McAfee Leaders appeared first on McAfee Blogs.
Over the past week we have seen a considerable body of work focusing on DarkSide, the ransomware responsible for the recent gas pipeline shutdown. Many of the excellent technical write-ups will detail how it operates an affiliate model that supports others to be involved within the ransomware business model (in addition to the developers). While this may not be a new phenomenon, this model is actively deployed by many groups with great effect. Herein is the crux of the challenge: while the attention may be on DarkSide ransomware, the harsh reality is that equal concern should be placed at Ryuk, or REVIL, or Babuk, or Cuba, etc. These, and other groups and their affiliates, exploit common entry vectors and, in many cases, the tools we see being used to move within an environment are the same. While this technical paper covers DarkSide in more detail, we must stress the importance of implementing best practices in securing/monitoring your network. These additional publications can guide you in doing so:
As mentioned earlier, DarkSide is a Ransomware-as-a-Service (RaaS) that offers high returns for penetration-testers that are willing to provide access to networks and distribute/execute the ransomware. DarkSide is an example of a RaaS whereby they actively invest in development of the code, affiliates, and new features. Alongside their threat to leak data, they have a separate option for recovery companies to negotiate, are willing to engage with the media, and are willing to carry out a Distributed Denial of Service (DDoS) attack against victims. Those victims who do pay a ransom receive an alert from DarkSide on companies that are on the stock exchange who are breached, in return for their payment. Potential legal issues abound, not to mention ethical concerns, but this information could certainly provide an advantage in short selling when the news breaks.
The group behind DarkSide are also particularly active. Using MVISION Insights we can identify the prevalence of targets. This map clearly illustrates that the most targeted geography is clearly the United States (at the time of writing). Further, the sectors primarily targeted are Legal Services, Wholesale, and Manufacturing, followed by the Oil, Gas and Chemical sectors.
McAfee’s market leading EPP solution covers DarkSide ransomware with an array of early prevention and detection techniques.
Customers using MVISION Insights will find a threat-profile on this ransomware family that is updated when new and relevant information becomes available.
MVISION EDR includes detections on many of the behaviors used in the attack including privilege escalation, malicious PowerShell and CobaltStrike beacons, and visibility of discovery commands, command and control, and other tactics along the attack chain. We have EDR telemetry indicating early detection before the detonation of the Ransomware payload.
ENS TP provides coverage against known indicators in the latest signature set. Updates on new indicators are pushed through GTI.
ENS ATP provides behavioral content focusing on proactively detecting the threat while also delivering known IoCs for both online and offline detections.
ENS ATP adds two (2) additional layers of protection thanks to JTI rules that provide attack surface reduction for generic ransomware behaviors and RealProtect (static and dynamic) with ML models targeting ransomware threats.
For the latest mitigation guidance, please review:
https://kc.mcafee.com/corporate/index?page=content&id=KB93354&locale=en_US
The RaaS platform offers the affiliate the option to build either a Windows or Unix version of the ransomware. Depending on what is needed, we observe that affiliates are using different techniques to circumvent detection, by masquerading the generated Windows binaries of DarkSide. Using several packers or signing the binary with a certificate are some of the techniques used to do so.
As peers in our industry have described, we also observed campaigns where the affiliates and their hacking crew used several ways to gain initial access to their victim’s network.
The configuration of the ransomware contains several options to enable or disable system processes, but also the above part where it states which processes should not be killed.
As mentioned before, a lot of the current Windows samples in the wild are the 1.8 version of DarkSide, others are the 2.1.2.3 version. In a chat one of the actors revealed that a V3 version will be released soon.
On March 23rd, 2021, on XSS, one of the DarkSide spokespersons announced an update of DarkSide as a PowerShell version and a major upgrade of the Linux variant:
In the current samples we observe, we do see the PowerShell component that is used to delete the Volume Shadow copies, for example.
Tools observed:
Before distributing the ransomware around the network using tools like PsExec and PowerShell, data was exfiltrated to Cloud Services that would later be used on the DarkSide Leak page for extortion purposes. Zipping the data, using Rclone or WinSCP are some of the examples observed.
While a lot of good and in-depth analyses are written by our peers, one thing worth noting is that when running DarkSide, the encryption process is fast. It is one of the areas the actors brag about on the same forum and do a comparison to convince affiliates to join their program:
DarkSide, like Babuk ransomware, has a Linux version. Both target *nix systems but in particular VMWare ESXi servers and storage/NAS. Storage/NAS is critical for many companies, but how many of you are running a virtual desktop, hosted on a ESXi server?
Darkside wrote a Linux variant that supports the encryption of ESXI server versions 5.0 – 7.1 as well as NAS technology from Synology. They state that other NAS/backup technologies will be supported soon.
In the code we clearly observe this support:
Also, the configuration of the Linux version shows it is clearly looking for Virtual Disk/memory kind of files:
Although the adversary recently claimed to vote for targets, the attacks are ongoing with packed and signed samples observed as recently as today (May 12, 2021):
Recently the Ransomware Task Force, a partnership McAfee is proud to be a part of, released a detailed paper on how ransomware attacks are occurring and how countermeasures should be taken. As many of us have published, presented on, and released research upon, it is time to act. Please follow the links included within this blog to apply the broader advice about applying available protection and detection in your environment against such attacks.
Data Encrypted for Impact – T1486
Inhibit System Recovery – T1490
Valid Accounts – T1078
PowerShell – T1059.001
Service Execution – T1569.002
Account Manipulation – T1098
Dynamic-link Library Injection – T1055.001
Account Discovery – T1087
Bypass User Access Control – T1548.002
File Permissions Modification – T1222
System Information Discovery – T1082
Process Discovery – T1057
Screen Capture – T1113
Compile After Delivery – T1027.004
Credentials in Registry – T1552.002
Obfuscated Files or Information – T1027
Shared Modules – T1129
Windows Management Instrumentation – T1047
Exploit Public-Facing Application – T1190
Phishing – T1566
External Remote Services – T1133
Multi-hop Proxy – T1090.003
Exploitation for Privilege Escalation – T1068
Application Layer Protocol – T1071
Bypass User Account Control – T1548.002
Commonly Used Port – T1043
Compile After Delivery – T1500
Credentials from Password Stores – T1555
Credentials from Web Browsers – T1555.003
Credentials in Registry – T1214
Deobfuscate/Decode Files or Information – T1140
Disable or Modify Tools – T1562.001
Domain Account – T1087.002
Domain Groups – T1069.002
Domain Trust Discovery – T1482
Exfiltration Over Alternative Protocol – T1048
Exfiltration to Cloud Storage – T1567.002
File and Directory Discovery – T1083
Gather Victim Network Information – T1590
Ingress Tool Transfer – T1105
Linux and Mac File and Directory Permissions Modification – T1222.002
Masquerading – T1036
Process Injection – T1055
Remote System Discovery – T1018
Scheduled Task/Job – T1053
Service Stop – T1489
System Network Configuration Discovery – T1016
System Services – T1569
Taint Shared Content – T1080
Unix Shell – T1059.004
The post DarkSide Ransomware Victims Sold Short appeared first on McAfee Blogs.
Today, Microsoft released a highly critical vulnerability (CVE-2021-31166) in its web server http.sys. This product is a Windows-only HTTP server which can be run standalone or in conjunction with IIS (Internet Information Services) and is used to broker internet traffic via HTTP network requests. The vulnerability is very similar to CVE-2015-1635, another Microsoft vulnerability in the HTTP network stack reported in 2015.
With a CVSS score of 9.8, the vulnerability announced has the potential to be both directly impactful and is also exceptionally simple to exploit, leading to a remote and unauthenticated denial-of-service (Blue Screen of Death) for affected products.
The issue is due to Windows improperly tracking pointers while processing objects in network packets containing HTTP requests. As HTTP.SYS is implemented as a kernel driver, exploitation of this bug will result in at least a Blue Screen of Death (BSoD), and in the worst-case scenario, remote code execution, which could be wormable. While this vulnerability is exceptional in terms of potential impact and ease of exploitation, it remains to be seen whether effective code execution will be achieved. Furthermore, this vulnerability only affects the latest versions of Windows 10 and Windows Server (2004 and 20H2), meaning that the exposure for internet-facing enterprise servers is fairly limited, as many of these systems run Long Term Servicing Channel (LTSC) versions, such as Windows Server 2016 and 2019, which are not susceptible to this flaw.
At the time of this writing, we are unaware of any “in-the-wild” exploitation for CVE-2021-31166 but will continue to monitor the threat landscape and provide relevant updates. We urge Windows users to apply the patch immediately wherever possible, giving special attention to externally facing devices that could be compromised from the internet. For those who are unable to apply Microsoft’s update, we are providing a “virtual patch” in the form of a network IPS signature that can be used to detect and prevent exploitation attempts for this vulnerability.
McAfee Network Security Platform (NSP) Protection
Sigset Version: 10.8.21.2
Attack ID: 0x4528f000
Attack Name: HTTP: Microsoft HTTP Protocol Stack Remote Code Execution Vulnerability (CVE-2021-31166)
McAfee Knowledge Base Article KB94510:
https://kc.mcafee.com/corporate/index?page=content&id=KB94510
The post Major HTTP Vulnerability in Windows Could Lead to Wormable Exploit appeared first on McAfee Blogs.
Countries all over the world are racing to achieve so-called herd immunity against COVID-19 by vaccinating their populations. From the initial lockdown to the cancellation of events and the prohibition of business travel, to the reopening of restaurants, and relaxation of COVID restrictions on outdoor gatherings, the vaccine rollout has played a critical role in staving off another wave of infections and restoring some degree of normalcy. However, a new and troubling phenomenon is that consumers are buying COVID-19 vaccines on the black market due to the increased demand around the world. As a result, illegal COVID-19 vaccines and vaccination records are in high demand on darknet marketplaces.
The impact on society is that the proliferation of fraudulent test results and counterfeit COVID-19 vaccine records pose a serious threat to public health and spur the underground economy. Individuals undoubtedly long to return to their pre-pandemic routines and the freedom of travel and behavior denied them over the last year. However, the purchase of false COVID-19 test certifications or vaccination cards to board aircraft, attend an event or enter a country endangers themselves, even if they are asymptomatic. It also threatens the lives of other people in their own communities and around the world. Aside from the collective damage to global health, darknet marketplace transactions encourage the supply of illicit goods and services. The underground economy cycle continues as demand creates inventory, which in turn creates supply. In addition to selling COVID-19 vaccines, vaccination cards, and fake test results, cybercriminals can also benefit by reselling the names, dates of birth, home addresses, contact details, and other personally indefinable information of their customers.
As we commemorate the one-year anniversary of the COVID-19 pandemic, at least 184 countries and territories worldwide have started their vaccination rollouts.[1] The United States is vaccinating Americans at an unprecedented rate. As of May 2021, more than 105 million Americans had been fully vaccinated. The growing demand has made COVID-19 vaccines the new “liquid gold” in the pandemic era.
However, following vaccination success, COVID-19 related cybercrime has increased. COVID-19 vaccines are currently available on at least a dozen darknet marketplaces. Pfizer-BioNTech COVID-19 vaccines (and we can only speculate as to whether they are genuine or a form of liquid “fool’s gold”) can be purchased for as little as $500 per dose from top-selling vendors. These sellers use various channels, such as Wickr, Telegram, WhatsApp and Gmail, for advertising and communications. Darknet listings associated with alleged Pfizer-BioNTech COVID-19 vaccines are selling for $600 to $2,500. Prospective buyers can receive the product within 2 to 10 days. Some of these supposed COVID-19 vaccines are imported from the United States, while others are packed in the United Kingdom and shipped to every country in the world, according to the underground advertisement.
Figure 1: Dark web marketplace offering COVID-19 vaccines
Figure 2: Dark web marketplace offering COVID-19 vaccines
A vendor sells 10 doses of what they claim to be Moderna COVID-29 vaccines for $2,000. According to the advertisement, the product is available to ship to the United Kingdom and worldwide.
Figure 3: Dark web marketplace offering COVID-19 vaccines
Besides what are claimed to be COVID-19 vaccines, cybercriminals offer antibody home test kits for $152 (again, we do not know whether they are genuine or not). According to the advertisement, there are various shipping options available. It costs $41 for ‘stealth’ shipping to the United States, $10.38 to ship to the United Kingdom, and $20 to mail the vaccines internationally.
Figure 4: Dark web marketplace offering COVID-19 test kits
On the darknet marketplaces, the sales of counterfeit COVID-19 test results and vaccination certificates began to outnumber the COVID vaccine offerings in mid-April. This shift is most likely because COVID-19 vaccines are now readily available for those who want them. People can buy and show these certificates without being vaccinated. A growing number of colleges will require students to have received a COVID-19 vaccine before returning to in-person classes by this fall.[2] Soon, COVID-19 vaccination proof is likely to become a requirement of some type of “passport” to board a plane or enter major events and venues.
The growing demand for proof of vaccination is driving an illicit economy for fake vaccination and test certificates. Opportunistic cybercriminals capitalize on public interest in obtaining a COVID-19 immunity passport, particularly for those who oppose COVID-19 vaccines or test positive for COVID-19 but want to return to school or work, resume travel or attend a public event. Counterfeit negative COVID-19 test results and COVID-19 vaccination cards are available for sale at various darknet marketplaces. Fake CDC-issued vaccination cards are available for $50. One vendor offers counterfeit German COVID-19 certificates for $23.35. Vaccination cards with customized information, such as “verified” batch or lot numbers for particular dates and “valid” medical and hospital information, are also available for purchase.
One darknet marketplace vendor offers to sell a digital copy of the COVID-19 vaccination card with detailed printing instructions for $50.
Figure 5: Dark web marketplace offering COVID-19 vaccination cards
One vendor sells CDC vaccination cards for $1,200 and $1,500, as seen in the following screenshot. These cards, according to the advertisement, can be personalized with details such as the prospective buyer’s name and medical information.
Figure 6: Dark web marketplace offering COVID-19 vaccination cards
Other darknet marketplace vendors offer fake CDC-issued COVID-19 vaccination card packages for $1,200 to $2,500. The package contains a PDF file that buyers can type and print, as well as personalized vaccination cards with “real” lot numbers, according to the advertisement. Prospective buyers can pay $1,200 for blank cards or $1,500 for custom-made cards with valid batch numbers, medical and hospital details.
Figure 7: Dark web marketplace offering COVID-19 vaccination cards
One vendor offers counterfeit negative COVID-19 test results and vaccine passports to potential buyers.
Figure 8: Dark web marketplace offering negative COVID-19 test results and vaccination cards
A seller on another dark web market sells five counterfeit German COVID-19 certificates for $23.35. According to the advertisement below, the product is available for shipping to Germany and the rest of the world.
Figure 9: Dark web marketplace offering German COVID-19 vaccination certificates
The proliferation of fraudulent test results and counterfeit COVID-19 vaccine records on darknet marketplaces poses a significant threat to global health while fueling the underground economy. While an increasing number of countries begin to roll out COVID-19 vaccines and proof of vaccination, questionable COVID vaccines and fake proofs are emerging on the underground market. With the EU and other jurisdictions opening their borders to those who have received vaccinations, individuals will be tempted to obtain false vaccination documents in their drive to a return to pre-pandemic normalcy that includes summer travel and precious time with missed loved ones. Those who buy questionable COVID-19 vaccines or forged vaccination certificates risk their own lives and the lives of others. Apart from the harm to global health, making payments to darknet marketplaces promotes the growth of illegal products and services. The cycle of the underground economy continues as demand generates inventory, which generates supply. These are the unintended consequences of an effective global COVID vaccine rollout.
[1] https[:]//www.cnn.com/interactive/2021/health/global-covid-vaccinations/
[2] https[:]//www.npr.org/2021/04/11/984787779/should-colleges-require-covid-19-vaccines-for-fall-more-campuses-are-saying-yes
The post “Fool’s Gold”: Questionable Vaccines, Bogus Results, and Forged Cards appeared first on McAfee Blogs.
At McAfee, we believe no one person, product or organization can combat cybercrime alone. That is why we continue to build our device-to-cloud security platform on the premise of working together – together with customers, partners and even other cybersecurity vendors. We continue this fight against the greatest challenges of our digital age: cybercrime. As part of our ongoing effort to protect what matters, we have developed breakthrough technologies over the past several years that enable customers to proactively respond to emerging threats and adversaries despite a constantly evolving threat landscape. So, today, we are extremely proud to announce that McAfee is positioned as a “Leader” in the 2021 Gartner Magic Quadrant for Endpoint Protection Platforms (EPP).
This is a monumental development in so many ways, especially when you consider that we were not recognized in the Magic Quadrant a few years ago. This recognition speaks volumes about the innovations we are bringing to market that resonate both with our customers and industry experts. Let me review, from my perspective, why McAfee is recognized in the Leaders Quadrant.
Here are some key innovations in our Endpoint Protection Platform that contributed to our Leader recognition:
We set out with a vision, to create the most powerful endpoint protection platform and we are aggressively executing towards this vision. Over the past 12 months, we have made great strides in developing a market leading product, MVISION Insights, and our cloud delivered MVISION EDR. Looking ahead, our goal is to develop a unified and open eXtended Detection and Response (XDR) solution and strategy that further delivers on our device-to-cloud strategy.
We believe, McAfee’s position as a Leader further acknowledges some of our key differentiators, such as MVISION Insights, and our ability to eclipse the market with an innovative device-to-cloud strategy that spans the portfolio, including web gateway, cloud, and our network security offerings.
We started by redefining our endpoint security offering with the release of MVISION Insights, a game-changing product that functions as the equivalent of an early warning system – effectively delivering preventative security. It’s hard to understate the significance of this innovation; we’re breaking the old paradigm of post-attack detection and analysis and enabling customers to stay ahead of threats. In parallel, we streamlined our EDR capabilities, which now provide AI-driven, guided investigations that ease the burden on already-stretched Security Operations Centers (SOCs).
The bottom line is that we’re the only vendor taking a proactive risk management approach for safer cloud usage while reducing total cost of ownership. In addition, we have improved our licensing structure to fit customer needs and simplify consumption of our endpoint security solutions. We’ve made it easy to choose from a simplified licensing structure allowing customers to buy subscriptions for complete endpoint protection with no add-ons or extra costs. Our user-based licensing agreements provide for 5 devices, thus enabling frictionless expansion to incorporate additional device support in remote work environments.
In just under a year, our latest release of McAfee Endpoint Security (ENS) 10.7 has emerged as our highest deployed version of any McAfee product worldwide and our fastest-ever single-year ramp. More than 15,000 customers comprising tens of millions of nodes are now on ENS 10.7 and are deploying its advanced defenses against escalating threats. Customers get added protected because ENS 10.7 is backed by our Global Threat Intelligence (GTI) service to provide adaptable, defense in-depth capabilities against the techniques used in targeted attacks, such as ransomware or fileless threats. It’s also easier to use and upgrade. All of this means your SOC can be assured that customers are protected with ENS 10.7 on their devices.
Customer input guides our thinking about what to do next. Since the best critics are the people who use our products, let’s give them the last word here.
“We are now positioned to block usage of personal instances of Sanctioned services while allowing the business to move forward with numerous cloud initiatives, without getting in the way. We also now have the visibility that was lacking to ensure that we can allow our user community to work safely from their homes without introducing risks to our corporate environment.”
–Kenn Johnson, Cybersecurity Consultant
Our continued commitment to our customers is to protect what matters. We believe that McAfee’s position in the Leaders Quadrant validates that we are innovating at the pace and scale that meets the most stringent needs of our enterprise customers. We are proud of our product teams and threat researchers who continue to be driven by our singular mission, and who strive to stay ahead of adversaries with their focus on technological breakthroughs, and advancements in researching threats and vulnerabilities.
What we have accomplished over the past several years, and our position as a Leader in the 2021 Gartner Magic Quadrant for EPP, is only the tip of the iceberg for what’s ahead.
McAfee named a Leader in the 2021 Gartner Magic Quadrant for Endpoint Protection Platforms. Download the Magic Quadrant report, which evaluates the 19 vendors based on ability to execute and completeness of vision.
Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
Gartner Magic Quadrant for Endpoint Protection Platforms, 5 May 2021 Paul Webber, Peter Firstbrook, Rob Smith , Mark Harris, Prateek Bhajanka
The post Gartner names McAfee a Leader in 2021 Magic Quadrant for Endpoint Protection Platforms appeared first on McAfee Blogs.
This year’s RSA Conference will look a little different. Instead of booking flights and hotel rooms in the busy city of San Francisco, we’ll be powering up computers in our home office with family in the next room. We’ve all had a tumultuous year and with that comes resilience, which is also this year’s conference theme.
Ahead of the RSA virtual conference, I spoke with a few of my colleagues about the major themes we should expect to see at RSA this year.
Scott Howitt, Senior Vice President and Chief Information Officer – The COVID lockdown has exposed to enterprises that the ability to recover your business (Business Continuity) is important in the face of disaster, but Business Resilience means that your business will be able to adapt to Black Swan events. I’ve seen technology be the catalyst for resilience for most organizations.
Raj Samani, Chief Scientist and McAfee Fellow – For me, it would be ability to continue operations in light of disruption. Whether that disruption originated from digital factors, or indeed physical but to keep the wheels turning.
John Fokker, Principal Engineer and Head of Cyber Investigations for McAfee ATR – Just like Boxing: Isn’t as much about not being hit, because you are in the ring and punches are thrown, but resilience to me is more about how fast you can get back up on your feet once you do get hit. The same is true with security operations, attackers are going to try to hit you, but how good is your defense so you can minimize the impact of the attack and in the case you do get knocked down what controls do you have in place that you can get back up and resume operations.
Amanda House, Data Scientist – Cybersecurity is a unique industry in that new cyberthreats are always improving to avoid detection. A machine learning model made a month ago could now have weakness an adversary has learned to exploit. Machine learning model practitioners need to be resilient in always innovating and improving on past models to outpace new threats. Resilience is constantly monitoring machine learning models so that when we notice decay we can quickly improve them to stop new cyberthreats.
Sherin Mathews, Senior Research Scientist – To me, cyber-resilience implies being able to protect critical assets, maintain operations, and, most importantly, embrace new technologies in the face of evolving threats. The cybersecurity field is an arms race scenario with the threat landscape changing so much. In case of threats like deepfakes, some deepfakes will reach ultra-realism in the coming few years, many will still be more amateurish, and we need to keep advancing towards the best detection methods with newer forms of threats. I feel resiliency doesn’t mean you can survive or defend against all attacks, but it means that if you are compromised, you have a plan that lets us recover quickly after a breach and continue to function. Deepfakes and other offshoots of AI will require businesses to create a transparent, agile, and holistic detection approach to protect endpoints, data, apps, and cloud services.
Samani – I anticipate Zero Trust will play a prominent role, considering the year of remote working, and a myriad of significant threats being realised.
Fokker – Definitely Zero-Trust but also combatting threats that come with working from home, and threat intelligence so organization can better understand the actions of their adversaries even before they step into the ring.
Howitt – I am hoping to see how others have adapted to life with COVID and now that it is receding, what do they think life with look like after. As for my session, I want to highlight the importance of adaptability and stress that this paradigm shift means we will never go back to normal.
House – Cybersecurity is not a career path I ever imagined for myself. As a student I always enjoyed math and computer science and I naturally gravitated toward those topics. My love of both subjects led me to pursue data science and machine learning. My first job out of college was in the cybersecurity industry and that was my first introduction to this career. Since then, I have loved how cybersecurity requires constant innovation and creative ways of using AI to stop new threats.
Mathews – My background and Ph.D. focused on developing novel dictionary learning and deep learning algorithms for classification tasks related to remote health monitoring systems (e.g., activity recognition for wearable sensors and heartbeat classification). With a background in machine learning, deep learning with applications to computer vision areas, I entered the field of cybersecurity during my work at Intel Security/Mcafee in 2016. I contributed towards increasing the effectiveness of cybersecurity products by creating novel machine learning/deep learning models to detect advanced threats(e.g., ransomware & steganography). In my industry work experience, I also had a chance to develop leading-edge research such as eXplainable A.I. (XAI) and deepfakes. Overall, the advent of artificial intelligence can be considered a significant milestone as A.I. is steadily flooding several industries. However, A.I. platforms can also be misused if in the wrong hands, and as research professionals, we need to step up to detect attacks or mishaps before they happen. I feel deeply passionate about XAI, ethical A.I., the opportunity to combat deepfakes and digital misinformation, and topics related to ML and DL with cybersecurity applications. Overall, it is an excellent feeling as a researcher to use your knowledge to combat threats that affect humanity and safeguard humans. Also, I believe that newer A.I. research topics such as GANs, Reinforcement learning, and few-shot learning have a lot to offer to combat advanced cybersecurity threats.
House – I am fortunate to work with a lot of great women in technology at McAfee. Not only are these women on the cutting edge of innovation but they are also great mentors and leaders. We need more smart people pursuing jobs in this industry and in order to recruit new talent, especially young graduates, we need to mentor and encourage them to pursue this career. Every woman I have met in this industry wants to see new talent succeed and will go the extra mile to provide mentorship. I have also noticed women tend to have unique backgrounds in this industry. For example, some of the women I look up to have degrees in biomedical engineering or physics. These unique backgrounds allow these women to bring innovative ideas from outside cybersecurity to solve some of the toughest problems in the cybersecurity industry. We need more talent from diverse backgrounds to bring in fresh ideas.
McAfee is a proud platinum with keynote level sponsor of RSA Conference 2021. Take in the McAfee virtual booth and sessions presented by McAfee industry leaders Here are some of the best ways to catch McAfee at RSA. Can’t wait to see you there!
The post RSA Conference 2021: The Best Place to Strengthen Your Resilience appeared first on McAfee Blogs.
The Roaming Mantis smishing campaign has been impersonating a logistics company to steal SMS messages and contact lists from Asian Android users since 2018. In the second half of 2020, the campaign improved its effectiveness by adopting dynamic DNS services and spreading messages with phishing URLs that infected victims with the fake Chrome application MoqHao.
Since January 2021, however, the McAfee Mobile Research team has established that Roaming Mantis has been targeting Japanese users with a new malware called SmsSpy. The malicious code infects Android users using one of two variants depending on the version of OS used by the targeted devices. This ability to download malicious payloads based on OS versions enables the attackers to successfully infect a much broader potential landscape of Android devices.
The phishing SMS message used is similar to that of recent campaigns, yet the phishing URL contains the term “post” in its composition.
|
Japanese message: I brought back your luggage because you were absent. please confirm. hxxps://post[.]cioaq[.]com
|
Fig: Smishing message impersonating a notification from a logistics company. (Source: Twitter)
Another smishing message pretends to be a Bitcoin operator and then directs the victim to a phishing site where the user is asked to verify an unauthorized login.
|
Japanese message: There is a possibility of abnormal login to your [bitFlyer] account. Please verify at the following URL: hxxps://bitfiye[.]com
|
Fig: Smishing message impersonating a notification from a bitcoin operator. (Source: Twitter)
During our investigation, we observed the phishing website hxxps://bitfiye[.]com redirect to hxxps://post.hygvv[.]com. The redirected URL contains the word “post” as well and follows the same format as the first screenshot. In this way, the actors behind the attack attempt to expand the variation of the SMS phishing campaign by redirecting from a domain that resembles a target company and service.
Characteristic of the malware distribution platform, different malware is distributed depending on the Android OS version that accessed the phishing page. On Android OS 10 or later, the fake Google Play app will be downloaded. On Android 9 or earlier devices, the fake Chrome app will be downloaded.
|
|
Japanese message in the dialog: “Please update to the latest version of Chrome for better security.” |
Fig: Fake Chrome application for download (Android OS 9 or less)
|
|
Japanese message in the dialog: “[Important] Please update to the latest version of Google Play for better security!”
|
Fig: Fake Google Play app for download (Android OS 10 or above)
Because the malicious program code needs to be changed with each major Android OS upgrade, the malware author appears to cover more devices by distributing malware that detects the OS, rather than attempting to cover a smaller set with just one type of malware
The main purpose of this malware is to steal phone numbers and SMS messages from infected devices. After it runs, the malware pretends to be a Chrome or Google Play app that then requests the default messaging application to read the victim’s contacts and SMS messages. It pretends to be a security service by Google Play on the latest Android device. Additionally, it can also masquerade as a security service on the latest Android devices. Examples of both are seen below.
|
|
Japanese message: “At first startup, a dialog requesting permissions is displayed. If you do not accept it, the app may not be able to start, or its functions may be restricted.”
|
Fig: Default messaging app request by fake Chrome app
|
|
Japanese message: “Secure Internet Security. Your device is protected. Virus and Spyware protection, Anti-phishing protection and Spam mail protection are all checked.” |
Fig: Default messaging app request by fake Google Play app
After hiding its icon, the malware establishes a WebSocket connection for communication with the attacker’s command and control (C2) server in the background. The default destination address is embedded in the malware code. It further has link information to update the C2 server location in the event it is needed. Thus, if no default server is detected, or if no response is received from the default server, the C2 server location will be obtained from the update link.
The MoqHao family hides C2 server locations in the user profile page of a blog service, yet some samples of this new family use a Chinese online document service to hide C2 locations. Below is an example of new C2 server locations from an online document:
Fig: C2 server location described in online document
As part of the handshake process, the malware sends the Android OS version, phone number, device model, internet connection type (4G/Wi-Fi), and unique device ID on the infected device to the C2 server.
Then it listens for commands from the C2 server. The sample we analyzed supported the commands below with the intention of stealing phone numbers in Contacts and SMS messages.
| Command String | Description |
| 通讯录 | Send whole contact book to server |
| 收件箱 | Send all SMS messages to server |
| 拦截短信&open | Start <Delete SMS message> |
| 拦截短信&close | Stop <Delete SMS message> |
| 发短信& | Command data contains SMS message and destination number, send them via infected device |
Table: Remote commands via WebSocket
We believe that the ongoing smishing campaign targeting Asian countries is using different mobile malware such as MoqHao, SpyAgent, and FakeSpy. Based on our research, the new type of malware discovered this time uses a modified infrastructure and payloads. We believe that there could be several groups in the cyber criminals and each group is developing their attack infrastructures and malware separately. Or it could be the work of another group who took advantage of previously successful cyber-attacks.
McAfee Mobile Security detects this threat as Android/SmsSpy and alerts mobile users if it is present and further protects them from any data loss. For more information about McAfee Mobile Security, visit https://www.mcafeemobilesecurity.com.
Phishing Domains:
| Domain | Registration Date |
| post.jpostp.com | 2021-03-15 |
| manag.top | 2021-03-11 |
| post.niceng.top | 2021-03-08 |
| post.hygvv.com | 2021-03-04 |
| post.cepod.xyz | 2021-03-04 |
| post.jposc.com | 2021-02-08 |
| post.ckerr.site | 2021-02-06 |
| post.vioiff.com | 2021-02-05 |
| post.cioaq.com | 2021-02-04 |
| post.tpliv.com | 2021-02-03 |
| posk.vkiiu.com | 2021-02-01 |
| sagawae.kijjh.com | 2021-02-01 |
| post.viofrr.com | 2021-01-31 |
| posk.ficds.com | 2021-01-30 |
| sagawae.ceklf.com | 2021-01-30 |
| post.giioor.com | 2021-01-30 |
| post.rdkke.com | 2021-01-29 |
| post.japqn.com | 2021-01-29 |
| post.thocv.com | 2021-01-28 |
| post.xkdee.com | 2021-01-27 |
| post.sagvwa.com | 2021-01-25 |
| post.aiuebc.com | 2021-01-24 |
| post.postkp.com | 2021-01-23 |
| post.solomsn.com | 2021-01-22 |
| post.civrr.com | 2021-01-21 |
| post.jappnve.com | 2021-01-19 |
| sp.vvsscv.com | 2021-01-16 |
| ps.vjiir.com | 2021-01-15 |
| post.jpaeo.com | 2021-01-12 |
| t.aeomt.com | 2021-01-2 |
| Hash | Package name | Fake Application |
| EA30098FF2DD1D097093CE705D1E4324C8DF385E7B227C1A771882CABEE18362 | com.gmr.keep | Chrome |
| 29FCD54D592A67621C558A115705AD81DAFBD7B022631F25C3BAAE954DB4464B | com.gmr.keep | Google Play |
| 9BEAD1455BFA9AC0E2F9ECD7EDEBFDC82A4004FCED0D338E38F094C3CE39BCBA | com.mr.keep | Google Play |
| D33AB5EC095ED76EE984D065977893FDBCC12E9D9262FA0E5BC868BAD73ED060 | com.mrc.keep | Chrome |
| 8F8C29CC4AED04CA6AB21C3C44CCA190A6023CE3273EDB566E915FE703F9E18E | com.hhz.keeping | Chrome |
| 21B958E800DB511D2A0997C4C94E6F0113FC4A8C383C73617ABCF1F76B81E2FD | com.hhz.keeping | Google Play |
| 7728EF0D45A337427578AAB4C205386CE8EE5A604141669652169BA2FBA23B30 | com.hz.keep3 | Chrome |
| 056A2341C0051ACBF4315EC5A6EEDD1E4EAB90039A6C336CC7E8646C9873B91A | com.hz.keep3 | Google Play |
| 054FA5F5AD43B6D6966CDBF4F2547EDC364DDD3D062CD029242554240A139FDB | com.hz.keep2 | Google Play |
| DD40BC920484A9AD1EEBE52FB7CD09148AA6C1E7DBC3EB55F278763BAF308B5C | com.hz.keep2 | Chrome |
| FC0AAE153726B7E0A401BD07C91B949E8480BAA0E0CD607439ED01ABA1F4EC1A | com.hz.keep1 | Google Play |
| 711D7FA96DFFBAEECEF12E75CE671C86103B536004997572ECC71C1AEB73DEF6 | com.hz.keep1 | Chrome |
| FE916D1B94F89EC308A2D58B50C304F7E242D3A3BCD2D7CCC704F300F218295F | com.hz.keep1 | Google Play |
| 3AA764651236DFBBADB28516E1DCB5011B1D51992CB248A9BF9487B72B920D4C | com.hz.keep1 | Chrome |
| F1456B50A236E8E42CA99A41C1C87C8ED4CC27EB79374FF530BAE91565970995 | com.hz.keep | Google Play |
| 77390D07D16E6C9D179C806C83D2C196A992A9A619A773C4D49E1F1557824E00 | com.hz.keep | Chrome |
| 49634208F5FB8BCFC541DA923EBC73D7670C74C525A93B147E28D535F4A07BF8 | com.hz.keep | Chrome |
| B5C45054109152F9FE76BEE6CBBF4D8931AE79079E7246AA2141F37A6A81CBA3 | com.hz.keep | Google Play |
| 85E5DBEA695A28C3BA99DA628116157D53564EF9CE14F57477B5E3095EED5726 | com.hz.keep | Chrome |
| 53A5DD64A639BF42E174E348FEA4517282C384DD6F840EE7DC8F655B4601D245 | com.hz.keep | Google Play |
| 80B44D23B70BA3D0333E904B7DDDF7E19007EFEB98E3B158BBC33CDA6E55B7CB | com.hz.keep | Chrome |
| 797CEDF6E0C5BC1C02B4F03E109449B320830F5ECE0AA6D194AD69E0FE6F3E96 | com.hz.keep | Chrome |
| 691687CB16A64760227DCF6AECFE0477D5D983B638AFF2718F7E3A927EE2A82C | com.hz.keep | Google Play |
| C88C3682337F7380F59DBEE5A0ED3FA7D5779DFEA04903AAB835C959DA3DCD47 | com.hz.keep | Google Play |
The post Roaming Mantis Amplifies Smishing Campaign with OS-Specific Android Malware appeared first on McAfee Blogs.
Email is one of the primary ways of communication in the modern world. We use email to receive notifications about our online shopping, financial transaction, credit card e-statements, one-time passwords to authenticate registration processes, application for jobs, auditions, school admissions and many other purposes. Since many people around the globe depend on electronic mail to communicate, phishing emails are an attack method favored by cyber criminals.
In this type of attack, cyber criminals design emails to look convincing and send them to targeted people. The sender pretends to be someone the potential victim knows, someone who can be trusted, like a friend, or close contact, or the very bank where they save their income, or even the social media platform where they might have an account. As soon as they click on any malicious files or links embedded within these emails, they may land in a compromised situation.
In this write up, I will focus on things to look at while hunting threats in phishing emails.
Header analysis:
An email is divided into three parts: header, body, and attachment. The header part keeps the routing information of the email. It may contain other information like content type, from, to, delivery date, sender origin, mail server, and the actual email address used to send/receive the email.
Important headers
Return- Path:
The Return-path email address receives the delivery status information. To get undelivered emails, or any other bounced back messages, our emails’ server uses Return-Path. The recipient server uses this field to identify spoof emails. In this process, the recipient server retrieves all the permitted IPs related to the sender domain and matches with the sender IP. If it fails to provide any match, we can consider the email to be spam.
Received:
This field shows information related to all hops, through which the email was transferred. The last entry shows the initial address of the email sender.
Reply-To:
This field’s email address is used to receive the reply message. It can differ from the address in spoof emails.
Received-SPF:
SPF (Sender Policy Framework) helps to verify that messages appearing from a particular domain were sent from servers under control of the actual owner. If the value is Pass, then the email source is valid.
DKIM:
Domain Keys Identified Mail (DKIM) signs the outgoing email with an encrypted signature inside the headers and the recipient email server decrypts it, using a shared public key to check whether the message was changed in transit.
X-Headers:
These headers are known as experimental or extension headers. They are usually added by the recipient mailbox providers. Fields like X-FOSE-Spam and X-Spam-Score are used to identify spam emails.
Consider the following email message:
Figure1: Raw email header information
Based on the above information the email is suspected to be spoofed. We should put the extracted email IDs in the block list.
The email bodies of phishing emails we usually receive mostly target our trust, by having something faithful and reliable in their content. It is so personalized and seemingly genuine, that victim’s often take the bait. Let us see the example below and understand what actions should be taken in such a scenario.
Figure2: Phishing email related to COVID-19
In the above email, the spammer pretends to be a medical insurance service provider and this mail is regarding a health-plan payment invoice for COVID-19 insurance the victim has supposedly purchased recently.
Figure2: Phishing email related to COVID-19 (continued)
Moreover, if we look closely at the bottom of the email, we can see the message, ‘This email has been scanned by McAfee’. This makes the email appear believable, as well as trustworthy.
Now, if we hover the mouse pointer over the |SEE DETAILS| button, one OneDrive link will pop up. Rather than clicking on the link, we must copy it for execution separately.
Figure3: Downloaded html file after clicking on the OneDrive link.
To execute the above OneDrive link separately (hxxps://1drv[.]ms/u/s!Ajmzc7fpBw5lrzwfPwIkoZRelG4D), it would be preferable to load it inside an isolated environment. If you do not have such an environment available yourself, you can use an online browser service like Browserling.
After loading the link in the browser, you will notice that it downloads an html attachment. Clicking on the html file takes us to another webpage (hxxps://selimyildiz[.]com.tr/wp-includes/fonts/greec/xls/xls/open/index.htm).
Figure4: Fake Office 365 login page
The content of the site is a lookalike of an online Microsoft Excel document where it is asking for Office 365 login details to download it. Before doing anything here we need to check a few more things.
Figure5: WordPress admin panel of selimyildiz[.]com.tr
To further validate whether the webpage is genuine or not, I have shortened the URL to its domain level to load it. The domain leads to a WordPress login page which does not belong to Microsoft, further arousing suspicion.
Figure 6: whois information of selimyildiz[.]com.tr
As per the whois information This domain has not been registered by Microsoft and it resolves to the public IP 2.56.152.159 which is also not owned by Microsoft. The information clearly indicates that it is not a genuine website.
Figure7: Attempting to login with random credentials to validate the authentication
Now to check the behavior, I came back to the login page, enter some random credentials, and try to download the invoice. As expected, I was faced with a login failed error. Here on we can assume there might be two probable reasons for the login failure. Firstly, to make the victim believe that it is a genuine login page or, secondly, to confirm whether the typed password is correct, as the victim may have made a typing error.
Figure8: Fake invoice to lure the victim
Now that we know this is fake, what is next? To validate the authentication check I entered random credentials again and bingo! This time it redirects to a pdf invoice, which looks genuine by showing it belongs to some medical company. However, the sad part is if the victim falls under this trap then, by the time they realize that this is a fake invoice, their login credentials will be phished.
In email, users commonly share two types of documents as an attachment, Microsoft office documents or PDF files. These are often used in document-based malware campaigns. To exploit the targeted systems, attackers usually infect these documents using VBA or JavaScript and distribute them via (phishing) emails.
In the first section of this part, we will analyze a malicious Word document. This type of document contains malicious Visual Basic Application (VBA) code, known as macros. Sometimes, a macro triggers the moment a document is opened, but from Microsoft Office 2007 onwards, a macro cannot execute itself until and unless the user enables the macro content. To deal with such showstoppers, attackers utilize various social engineering methods, where the primary goal is to build trust with the victim so that they click on the ‘Enable Editing’ button without any second thought.
File Name: PR_Report.bin
Hash: e992ffe746b40d97baf56098e2110ff3978f8229ca333e87e24d1539cea7415c
Tools:
Step 1: Getting started with File properties
It is always good practice to get familiar with the properties before starting any file analysis. We can get the details using the ‘file’ command in Linux.
Step 2: Apply Yara rules
Yara is a tool to identify and classify malware. This tool is used to conduct signature-based detection against any file. Let us check a couple of premade Yara rules from Didier Stevens Suites.
Step 3: Dump the document contents using oledump.py
As we know, an OLE file contains streams of data. Oledump.py will help us to analyze those streams further to extract macros or objects out of it.
You may notice in the above figure that we can see two letters ‘M‘ and ‘O’ in stream 8, 9 and 15, respectively. Here ‘M’ indicates the stream might contain macro code and ‘O’ indicates an object.
Step 4: Extract the VB script in macros
Shell cmd.exe /c ping localhost -n 100 && start Environ(“Temp”) & “\6C.pif”, vbHide
Step 5: Extract file from the ole object.
It is clear that the document has an embedded file which can be extracted using the oleobj tool.
Step 6: Getting the static information from the extracted file.
Step 7: Behavior analysis
Setup a Windows 7 32-bit VM, change the file extension to ‘.exe’ and simply run Apate DNS and Windows Network Monitoring tool before execution.
Figure9: Command and Control domain’s DNS queries captured in Apate DNS
Figure10: Captured network traffic of 5C.exe while trying to communicate with the C2
Figure11: Registry changes captured in Process Monitor
We can summarize it as the Word document first ran a VBA macro, dropped and ran an embedded executable, created a new process, communicated with the C2 servers and made unauthorized Registry changes. This is enough information to consider the document as malicious. From this point, if we want, we can do more detailed analysis like debugging the executable or analyzing the process dump to learn more about the file behavior.
A PDF document can be defined as a collection of objects that describes how the pages should be displayed inside the file.
Usually, an attack vector uses email or other social engineering skills to lure the user to click or open the pdf document. The moment a user opens the pdf file it typically executes JavaScript in the background that may exploit the existing vulnerability that persist with the Adobe pdf reader or drop an executable as a payload that might perform the rest of the objectives.
A pdf file has four components. They are header, body, reference, and trailer.
File name: Report.pdf
Sha256: a7b423202d5879d1f9e47ae85ce255e3758c5c1e5b19fcd56691dab288a47b4c
Tools –
Step 1: Scan the pdf document with PDFiD
PDFiD is a part of the Didier Stevens Suite. It scans the pdf document with a list of strings, which helps you to identify the information like JavaScript, Embedded files, actions while opening the documents and the count of the occurrences of some specific strings inside the pdf file.
Step 2: Looking inside the Objects
We have now discovered that there is JavaScript present inside the pdf file so let us start from there. We will run pdf-parser.py to search the JavaScript indirect object.
Step 3: Extract the embedded file using peepdf.
Peepdf is a tool built in Python, which provides all the necessary components in one place that are required during PDF analysis.
Syntax: peepdf –i file_name.pdf
The syntax (-i) means enabling interaction mode.
To learn more, just type help with the topic and explore the options it displays.
Step 4: Behavior analysis
Now set up a windows 7 32-bit virtual machine and execute the file.
Figure12: Process Explorer displays processes created by virus.exe
Figure13: Process Monitor captured the system changes made by virus.exe
The results in Process Monitor show the file was dropped as zedeogm.exe. Later it modified the Windows firewall rule. Then it executed WinMail.exe, following which it started cmd.exe to execute ‘tmpd849fc4d.bat’ and exited the process.
At this point, we have collected enough evidence to treat the pdf file as malicious. We can also perform additional precautionary steps like binary debugging and memory forensics on the extracted IOCs to hunt for further threats
In this write-up, we have understood the purpose of email threat hunting, how it will help to take preventive actions against un-known threats. We have discovered the areas we should investigate for hunting threats. We learned how a malicious URL can be hidden inside an email body and its analysis to further see if it is malicious or not.
To stay protected:
The post Steps to Discover Hidden Threat from Phishing Email appeared first on McAfee Blogs.
McAfee is tracking an increase in the use of deceptive popups that mislead some users into taking action, while annoying many others. A significant portion is attributed to browser-based push notifications, and while there are a couple of simple steps users can take to prevent and remediate the situation, there is also some confusion about how these should be handled.
In many cases scammers use deception to trick users into Allowing push notifications to be delivered to their system.
In other cases, there is no deception involved. Users willingly opt-in uncoerced.
After Allowing notifications, messages quickly start being received. Some sites send notifications as often as every minute.
Many messages are deceptive in nature. Consider this fake alert example. Clicking the message leads to an imposter Windows Defender alert website, complete with MP3 audio and a phone number to call.
In several other examples, social engineering is crafted around the McAfee name and logo. Clicking on the messages lead to various websites informing the user their subscription has expired, that McAfee has detected threats on their system, or providing direct links to purchase a McAfee subscription. Note that “Remove Ads” and similar notification buttons typically lead to the publishers chosen destination rather than anything that would help the user in disabling the popups. Also note that many of the destination sites themselves prompt the user to Allow more notifications. This can have a cascading effect where the user is soon flooded with many messages on a regular basis.
First, it’s important to understand that the representative images provided here are not indications of a virus infection. It is not necessary to update or purchase software to resolve the matter. There is a simple fix:
1. Note the name of the site sending the notification in the popup itself. It’s located next to the browser name, for example:
Example popup with a link to a Popup remover
2. Go to your browser settings’ notification section
3. Search for the site name and click the 3 dotes next to the entry.
Chrome’s notification settings
4. Select Block
The simplest way is to carefully read such authorization prompts and only click Allow on sites that you trust. Alternatively, you can disable notification prompts altogether.
As the saying goes, an ounce of prevention is worth a pound of cure.
While there are thousands of various messages and sites sending them, and messages evolve over time, these are the most common seen in April 2021:
|Click here to review your PC protection|Reminder From McAfee|Click here to review your PC protection|Download your free Windows protection now.|Bestes Antivirus–Kostenlos herunterladen
Your Mcafee has Expired |Renew now to stay protected for your PC!
Activate McAfee Antivirus Your Mcafee has Expired | Renew Norton Antivirus!The post How to Stop the Popups appeared first on McAfee Blogs.
Many malware attacks designed to inflict damage on a network are armed with lateral movement capabilities. Post initial infection, such malware would usually need to perform a higher privileged task or execute a privileged command on the compromised system to be able to further enumerate the infection targets and compromise more systems on the network. Consequently, at some point during its lateral movement activities, it would need to escalate its privileges using one or the other privilege escalation techniques. Once malware or an attacker successfully escalates its privileges on the compromised system, it will acquire the ability to perform stealthier lateral movement, usually executing its tasks under the context of a privileged user, as well as bypassing mitigations like User Account Control.
Process access token manipulation is one such privilege escalation technique which is widely adopted by malware authors. These set of techniques include process access token theft and impersonation, which eventually allows malware to advance its lateral movement activities across the network in the context of another logged in user or higher privileged user.
When a user authenticates to Windows via console (interactive logon), a logon session is created, and an access token is granted to the user. Windows manages the identity, security, or access rights of the user on the system with this access token, essentially determining what system resources they can access and what tasks can be performed. An access token for a user is primarily a kernel object and an identification of that user in the system, which also contains many other details like groups, access rights, integrity level of the process, privileges, etc. Fundamentally, a user’s logon session has an access token which also references their credentials to be used for Windows single sign on (SSO) authentication to access the local or remote network resources.
Once the attacker gains an initial foothold on the target by compromising the initial system, they would want to move around the network laterally to access more resource or critical assets. One of the ways for an attacker to achieve this is to use the identity or credentials of already logged-on users on the compromised machine to pivot to other systems or escalate their privileges and perform the lateral movement in the context of another logged on higher privileged user. Process access token manipulation helps the attackers to precisely accomplish this goal.
For our YARA rule, MITRE ATT&CK techniques and to learn more about the technical details of token manipulation attacks and how malware executes these attacks successfully at the code level, read our complete technical analysis here.
McAfee On-Access-Scan has a generic detection for this nature of malware as shown in the below screenshot:
Additionally, the YARA rule mentioned at the end of the technical analysis document can also be used to detect the token manipulation attacks by importing the rule in the Threat detection solutions like McAfee Advance Threat Defence, this behaviour can be detected.
Several types of malware and advanced persistent threats abuse process tokens to gain elevated privileges on the system. Malware can take multiple routes to achieve this goal. However, in all these routes, it would abuse the Windows APIs to execute the token stealing or token impersonation to gain elevated privileges and advance its lateral movement activities.
Access Token Theft and Manipulation Attacks – A Door to Local Privilege Escalation.
The post Access Token Theft and Manipulation Attacks – A Door to Local Privilege Escalation appeared first on McAfee Blogs.
A new wave of fraudulent apps has made its way to the Google Play store, targeting Android users in Southwest Asia and the Arabian Peninsula as well—to the tune of more than 700,000 downloads before detection by McAfee Mobile Research and co-operation with Google to remove the apps.
Figure 1. Infected Apps on Google Play
Posing as photo editors, wallpapers, puzzles, keyboard skins, and other camera-related apps, the malware embedded in these fraudulent apps hijack SMS message notifications and then make unauthorized purchases. While apps go through a review process to ensure that they are legitimate, these fraudulent apps made their way into the store by submitting a clean version of the app for review and then introducing the malicious code via updates to the app later.
Figure 2. Negative reviews on Google Play
McAfee Mobile Security detects this threat as Android/Etinu and alerts mobile users if they are present. The McAfee Mobile Research team continues to monitor this threat and is likewise continuing its co-operation with Google to remove these and other malicious applications on Google Play.
In terms of details, the malware embedded in these apps takes advantage of dynamic code loading. Encrypted payloads of malware appear in the assets folder associated with the app, using names such as “cache.bin,” “settings.bin,” “data.droid,” or seemingly innocuous “.png” files, as illustrated below.
Figure 3. Encrypted resource sneaked into the assets folder
Figure 4. Decryption flow
The figure above shows the decryption flow. Firstly, the hidden malicious code in the main .apk opens “1.png” file in the assets folder, decrypts it to “loader.dex,” and then loads the dropped .dex. The “1.png” is encrypted using RC4 with the package name as the key. The first payload creates HTTP POST request to the C2 server.
Interestingly, this malware uses key management servers. It requests keys from the servers for the AES encrypted second payload, “2.png”. And the server returns the key as the “s” value of JSON. Also, this malware has self-update function. When the server responds “URL” value, the content in the URL is used instead of “2.png”. However, servers do not always respond to the request or return the secret key.
Figure 5. Updated payload response
As always, the most malicious functions reveal themselves in the final stage. The malware hijacks the Notification Listener to steal incoming SMS messages like Android Joker malware does, without the SMS read permission. Like a chain system, the malware then passes the notification object to the final stage. When the notification has arisen from the default SMS package, the message is finally sent out using WebView JavaScript Interface.
Figure 6. Notification delivery flow
As a result of our additional investigation on C2 servers, following information was found, including carrier, phone number, SMS message, IP address, country, network status, and so forth—along with auto-renewing subscriptions:
Figure 7. Leaked data
We expect that threats which take advantage of Notification Listener will continue to flourish. The McAfee Mobile Research team continues to monitor these threats and protect customers by analyzing potential malware and working with app stores to remove it. Further, using McAfee Mobile Security can detect such threats and protect you from them via its regular updates. However, it’s important to pay attention to apps that request SMS-related permissions and Notification Listener permissions. Simply put, legitimate photo and wallpaper apps simply won’t ask for those because they’re not necessary for such apps to run. If a request seems suspicious, don’t allow it.
MITRE ATT&CK Matrix
| 08C4F705D5A7C9DC7C05EDEE3FCAD12F345A6EE6832D54B758E57394292BA651 | com.studio.keypaper2021 |
| CC2DEFEF5A14F9B4B9F27CC9F5BBB0D2FC8A729A2F4EBA20010E81A362D5560C | com.pip.editor.camera |
| 007587C4A84D18592BF4EF7AD828D5AAA7D50CADBBF8B0892590DB48CCA7487E | org.my.favorites.up.keypaper |
| 08FA33BC138FE4835C15E45D1C1D5A81094E156EEF28D02EA8910D5F8E44D4B8 | com.super.color.hairdryer |
| 9E688A36F02DD1B1A9AE4A5C94C1335B14D1B0B1C8901EC8C986B4390E95E760 | com.ce1ab3.app.photo.editor |
| 018B705E8577F065AC6F0EDE5A8A1622820B6AEAC77D0284852CEAECF8D8460C | com.hit.camera.pip |
| 0E2ACCFA47B782B062CC324704C1F999796F5045D9753423CF7238FE4CABBFA8 | com.daynight.keyboard.wallpaper |
| 50D498755486D3739BE5D2292A51C7C3D0ADA6D1A37C89B669A601A324794B06 | com.super.star.ringtones |
d37i64jgpubcy4.cloudfront.net
d1ag96m0hzoks5.cloudfront.net
dospxvsfnk8s8.cloudfront.net
d45wejayb5ly8.cloudfront.net
d3u41fvcv6mjph.cloudfront.net
d3puvb2n8wcn2r.cloudfront.net
d8fkjd2z9mouq.cloudfront.net
d22g8hm4svq46j.cloudfront.net
d3i3wvt6f8lwyr.cloudfront.net
d1w5drh895wnkz.cloudfront.net
The post Clever Billing Fraud Applications on Google Play: Etinu appeared first on McAfee Blogs.
After experiencing a health scare that changed his life, VP of Technology Services, Paul, vowed to make incremental changes by incorporating four important health pledges into his daily routine.
Hear Paul’s life-changing story, how his diagnosis impacted his outlook on prioritizing his physical and mental health, and how he describes McAfee’s role in empowering him and others to follow their own wellness goals.
“To the leadership team and colleagues around me, thank you for giving me the time, space and flexibility to recover. The fact that we can 100% check out and focus on our wellbeing is paramount. At McAfee, that’s in our culture and our spirit.”
Here are Paul’s recommendations of four daily practices that every person can incorporate daily into their busy schedules.
Get up and Walk
Plan for virtual 1:1 walking meetings with your team, it allows you to stay active even on the busiest days.
Hydrate
Keep a cannister of ice, cold water at your desk so that you can stay hydrated throughout the workday.
Takes Breaks
Take mental breaks and intentionally unplug. Spend time away from your electronic devices by avoiding emails or going on chat.
Stand Up
It can be easy to sit at your desk all day. This doesn’t benefit your health. Instead, stand up and find ways to move.
At McAfee, we believe that your mental and physical wellbeing is a top priority. That’s why we encourage team members to take the time they need to reset, recharge, and care for their health. Between our paid holidays, unlimited vacation policy in the U.S., and leave policy, we enable our team to balance work with life’s responsibilities. We know that the key to living our best lives at and away from the office starts with focusing on wellbeing.
Want to work for a company that encourages team members to prioritize their health and wellbeing? Check out McAfee’s Latest Career Opportunities. Subscribe to Job Alerts.
Stay Connected
For more stories like this, follow @LifeAtMcAfee on Instagram and @McAfee on Twitter to see what working at McAfee is all about.
Search Career Opportunities with McAfee
Interested in joining our team? We’re hiring! Apply now.
The post McAfee VP Shares His Four Pledges for a Healthier Lifestyle appeared first on McAfee Blogs.
In a year where people relied on their digital lives more than ever before and a dramatic uptick in attacks quickly followed, McAfee’s protection stood strong.
We’re proud to announce several awards from independent third-party labs, which recognized our products, protection, and the people behind them over the course of last year.
The Cybersecurity Excellence Awards is an annual competition honoring individuals and companies that demonstrate excellence, innovation, and leadership in information security. We were honored with four awards:
Further recognition came by way of three independent labs known for their testing and evaluation of security products. Once more, this garnered several honors:
As the threat landscape continues to evolve, our products do as well. We’re continually updating them with new features and enhancements, which our subscribers receive as part of automatic product updates. So, if you bought your product one or two years ago, know that you’re still getting the latest award-winning protection with your subscription.
We’d like to acknowledge your part in these awards as well. None of this is possible without the trust you place in us and our products. With the changes in our work, lifestyles, and learning that beset millions of us this past year, your protection and your feeling of security remain our top priority.
With that, as always, thank you for selecting us.
To stay updated on all things McAfee and on top of the latest consumer and mobile security threats, follow @McAfee_Home on Twitter, subscribe to our email, listen to our podcast Hackable?, and ‘Like’ us on Facebook.
The post McAfee Awarded “Cybersecurity Excellence Awards” appeared first on McAfee Blogs.
The McAfee Advanced Threat Research team today published the McAfee Labs Threats Report: April 2021.
In this edition, we present new findings in our traditional threat statistical categories – as well as our usual malware, sectors, and vectors – imparted in a new, enhanced digital presentation that’s more easily consumed and interpreted.
Historically, our reports detailed the volume of key threats, such as “what is in the malware zoo.” The introduction of MVISION Insights in 2020 has since made it possible to track the prevalence of campaigns, as well as, their associated IoCs, and determine the in-field detections. This latest report incorporates not only the malware zoo but new analysis for what is being detected in the wild.
The Q3 and Q4 2020 findings include:
Additional Q3 and Q4 2020 content includes:
These new, insightful additions really make for a bumper report! We hope you find this new McAfee Labs threat report presentation and data valuable.
Don’t forget keep track of the latest campaigns and continuing threat coverage by visiting our McAfee COVID-19 Threats Dashboard and the MVISION Insights preview dashboard.
The post McAfee Labs Report Reveals Latest COVID-19 Threats and Malware Surges appeared first on McAfee Blogs.
Recently, the McAfee Mobile Research Team uncovered several new variants of the Android malware family BRATA being distributed in Google Play, ironically posing as app security scanners.
These malicious apps urge users to update Chrome, WhatsApp, or a PDF reader, yet instead of updating the app in question, they take full control of the device by abusing accessibility services. Recent versions of BRATA were also seen serving phishing webpages targeting users of financial entities, not only in Brazil but also in Spain and the USA.
In this blog post we will provide an overview of this threat, how does this malware operates and its main upgrades compared with earlier versions. If you want to learn more about the technical details of this threat and the differences between all variants you can check the BRATA whitepaper here.
First seen in the wild at the end of 2018 and named “Brazilian Remote Access Tool Android ” (BRATA) by Kaspersky, this “RAT” initially targeted users in Brazil and then rapidly evolved into a banking trojan. It combines full device control capabilities with the ability to display phishing webpages that steal banking credentials in addition to abilities that allow it capture screen lock credentials (PIN, Password or Pattern), capture keystrokes (keylogger functionality), and record the screen of the infected device to monitor a user’s actions without their consent.
Because BRATA is distributed mainly on Google Play, it allows bad actors to lure victims into installing these malicious apps pretending that there is a security issue on the victim’s device and asking to install a malicious app to fix the problem. Given this common ruse, it is recommended to avoid clicking on links from untrusted sources that pretend to be a security software which scans and updates your system—e even if that link leads to an app in Google Play. McAfee offers protection against this threat via McAfee Mobile Security, which detects this malware as Android/Brata.
The main upgrades and changes that we have identified in the latest versions of BRATA recently found in Google Play include:
During 2020, the threat actors behind BRATA have managed to publish several apps in Google Play, most of them reaching between one thousand to five thousand installs. However, also a few variants have reached 10,000 installs including the latest one, DefenseScreen, reported to Google by McAfee in October and later removed from Google Play.
Figure 1. DefenseScreen app in Google Play.
From all BRATA apps that were in Google Play in 2020, five of them caught our attention as they have notable improvements compared with previous ones. We refer to them by the name of the developer accounts:
Figure 2. Timeline of identified apps in Google Play from May to October 2020
BRATA poses as a security app scanner that pretends to scan all the installed apps, while in the background it checks if any of the target apps provided by a remote server are installed in the user’s device. If that is the case, it will urge the user to install a fake update of a specific app selected depending on the device language. In the case of English-language apps, BRATA suggests the update of Chrome while also constantly showing a notification at the top of the screen asking the user to activate accessibility services:
Figure 3. Fake app scanning functionality
Once the user clicks on “UPDATE NOW!”, BRATA proceeds to open the main Accessibility tab in Android settings and asks the user to manually find the malicious service and grant permissions to use accessibility services. When the user attempts to do this dangerous action, Android warns of the potential risks of granting access to accessibility services to a specific app, including that the app can observe your actions, retrieve content from Windows, and perform gestures like tap, swipe, and pinch.
As soon as the user clicks on OK the persistent notification goes away, the main icon of the app is hidden and a full black screen with the word “Updating” appears, which could be used to hide automated actions that now can be performed with the abuse of accessibility services:
Figure 4. BRATA asking access to accessibility services and showing a black screen to potentially hide automated actions
At this point, the app is completely hidden from the user, running in the background in constant communication with a command and control server run by the threat actors. The only user interface that we saw when we analyzed BRATA after the access to accessibility services was granted was the following screen, created by the malware to steal the device PIN and use it to unlock it when the phone is unattended. The screen asks the user to confirm the PIN, validating it with the real one because when an incorrect PIN is entered, an error message is shown and the screen will not disappear until the correct PIN is entered:
Figure 5. BRATA attempting to steal device PIN and confirming if the correct one is provided
Once the malicious app is executed and accessibility permissions have been granted, BRATA can perform almost any action in the compromised device. Here’s the list of commands that we found in all the payloads that we have analyzed so far:
In addition to the commands above, BRATA also performs automated actions by abusing accessibility services to hide itself from the user or automatically grant privileges to itself:
Earlier BRATA versions like OutProtect and PrivacyTitan were designed to target Brazilian users only by limiting its execution to devices set to the Portuguese language in Brazil. However, in June we noticed that threat actors behind BRATA started to add support to other languages like Spanish and English. Depending on the language configured in the device, the malware suggested that one of the following three apps needed an urgent update: WhatsApp (Spanish), a non-existent PDF Reader (Portuguese) and Chrome (English):
Figure 6. Apps falsely asked to be updated depending on the device language
In addition to the localization of the user-interface strings, we also noticed that threat actors have updated the list of targeted financial apps to add some from Spain and USA. In September, the target list had around 52 apps but only 32 had phishing URLs. Also, from the 20 US banking apps present in the last target list only 5 had phishing URLs. Here’s an example of phishing websites that will be displayed to the user if specific US banking apps are present in the compromised device:
Figure 7. Examples of phishing websites pretending to be from US banks
Throughout 2020, BRATA constantly evolved, adding different obfuscation layers to impede its analysis and detection. One of the first major changes was moving its core functionality to a remote server so it can be easily updated without changing the original malicious application. The same server is used as a first point of contact to register the infected device, provide an updated list of targeted financial apps, and then deliver the IP address and port of the server that will be used by the attackers to execute commands remotely on the compromised device:
Figure 8. BRATA high level network communication
Additional protection layers include string obfuscation, country and language check, encryption of certain key strings in assets folder, and, in latest variants, the use of a commercial packer that further prevents the static and dynamic analysis of the malicious apps. The illustration below provides a summary of the different protection layers and execution stages present in the latest BRATA variants:
Figure 9. BRATA protection layers and execution stages
In order get infected with BRATA ,users must install the malicious application from Google Play so below are some recommendations to avoid being tricked by this or any other Android threats that use social engineering to convince users to install malware that looks legitimate:
The activation of accessibility services is very sensitive in Android and key to the successful execution of this banking trojan because, once the access to those services is granted, BRATA can perform all the malicious activities and take control of the device. For this reason, Android users must be very careful when granting this access to any app.
Accessibility services are so powerful that in hands of a malicious app they could be used to fully compromise your device data, your online banking and finances, and your digital life overall.
When BRATA was initially discovered in 2019 and named “Brazilian Android RAT” by Kaspersky, it was said that, theoretically, the malware can be used to target other users if the cybercriminals behind this threat wanted to do it. Based on the newest variants found in 2020, the theory has become reality, showing that this threat is currently very active, constantly adding new targets, new languages and new protection layers to make its detection and analysis more difficult.
In terms of functionality, BRATA is just another example of how powerful the (ab)use of accessibility services is and how, with just a little bit of social engineering and persistence, cybercriminals can trick users into granting this access to a malicious app and basically getting total control of the infected device. By stealing the PIN, Password or Pattern, combined with the ability to record the screen, click on any button and intercept anything that is entered in an editable field, malware authors can virtually get any data they want, including banking credentials via phishing web pages or even directly from the apps themselves, while also hiding all these actions from the user.
Judging by our findings, the number of apps found in Google Play in 2020 and the increasing number of targeted financial apps, it looks like BRATA will continue to evolve, adding new functionality, new targets, and new obfuscation techniques to target as many users as possible, while also attempting to reduce the risk of being detected and removed from the Play store.
McAfee Mobile Security detects this threat as Android/Brata. To protect yourselves from this and similar threats, employ security software on your mobile devices and think twice before granting access to accessibility services to suspicious apps, even if they are downloaded from trusted sources like Google Play.
Figure 10. MITRE ATT&CK Mobile for BRATA
<h3>Indicators of compromise
Apps:
| SHA256 | Package Name | Installs |
| 4cdbd105ab8117620731630f8f89eb2e6110dbf6341df43712a0ec9837c5a9be | com.outprotect.android | 1,000+ |
| d9bc87ab45b0c786aa09f964a8101f6df7ea76895e2e8438c13935a356d9116b | com.privacytitan.android | 1,000+ |
| f9dc40a7dd2a875344721834e7d80bf7dbfa1bf08f29b7209deb0decad77e992 | com.greatvault.mobile | 10,000+ |
| e00240f62ec68488ef9dfde705258b025c613a41760138b5d9bdb2fb59db4d5e | com.pw.secureshield | 5,000+ |
| 2846c9dda06a052049d89b1586cff21f44d1d28f153a2ff4726051ac27ca3ba7 | com.defensescreen.application | 10,000+ |
URLs:
This paper will analyze five different “Brazilian Remote Access Tool Android” (BRATA) apps found in Google Play during 2020.
The post BRATA Keeps Sneaking into Google Play, Now Targeting USA and Spain appeared first on McAfee Blogs.
Cuba ransomware is an older ransomware, that has recently undergone some development. The actors have incorporated the leaking of victim data to increase its impact and revenue, much like we have seen recently with other major ransomware campaigns.
In our analysis, we observed that the attackers had access to the network before the infection and were able to collect specific information in order to orchestrate the attack and have the greatest impact. The attackers operate using a set of PowerShell scripts that enables them to move laterally. The ransom note mentions that the data was exfiltrated before it was encrypted. In similar attacks we have observed the use of a Cobalt Strike payload, although we have not found clear evidence of a relationship with Cuba ransomware.
We observed Cuba ransomware targeting financial institutions, industry, technology and logistics organizations.
The following picture shows an overview of the countries that have been impacted according to our telemetry.
Defenders should be on the lookout for traces and behaviours that correlate to open source pen test tools such as winPEAS, Lazagne, Bloodhound and Sharp Hound, or hacking frameworks like Cobalt Strike, Metasploit, Empire or Covenant, as well as abnormal behavior of non-malicious tools that have a dual use. These seemingly legitimate tools (e.g., ADfind, PSExec, PowerShell, etc.) can be used for things like enumeration and execution. Subsequently, be on the lookout for abnormal usage of Windows Management Instrumentation WMIC (T1047). We advise everyone to check out the following blogs on evidence indicators for a targeted ransomware attack (Part1, Part2).
Looking at other similar Ransomware-as-a-Service families we have seen that certain entry vectors are quite common among ransomware criminals:
When it comes to the actual ransomware binary, we strongly advise updating and upgrading endpoint protection, as well as enabling options like tamper protection and Rollback. Please read our blog on how to best configure ENS 10.7 to protect against ransomware for more details.
For active protection, more details can be found on our website – https://www.mcafee.com/enterprise/en-us/threat-center/threat-landscape-dashboard/ransomware-details.cuba-ransomware.html – and in our detailed Defender blog.
Learn more about Cuba ransomware, Yara Rules, Indicators of Compromise & Mitre ATT&CK techniques used by reading our detailed technical analysis.
The post McAfee ATR Threat Report: A Quick Primer on Cuba Ransomware appeared first on McAfee Blogs.
Over the past year, we have seen ransomware attackers change the way they have responded to organizations that have either chosen to not pay the ransom or have recovered their data via some other means. At the end of the day, fighting ransomware has resulted in the bad actors’ loss of revenue. Being the creative bunch they are, they have resorted to data dissemination if the ransom is not paid. This means that significant exposure could still exist for your organization, even if you were able to recover from the attack.
Cuba ransomware, no newcomer to the game, has recently introduced this behavior.
This blog is focused on how to build an adaptable security architecture to increase your resilience against these types of attacks and specifically, how McAfee’s portfolio delivers the capability to prevent, detect and respond against the tactics and techniques used in the Cuba Ransomware Campaign.
As always, building adaptable defensive architecture starts with intelligence. In most organizations, the Security Operations team is responsible for threat intelligence analysis, as well as threat and incident response. McAfee Insights (https://www.mcafee.com/enterprise/en-us/lp/insights-dashboard1.html#) is a great tool for the threat intel analyst and threat responder. The Insights Dashboard identifies prevalence and severity of emerging threats across the globe which enables the Security Operations Center (SOC) to prioritize threat response actions and gather relevant cyber threat intelligence (CTI) associated with the threat, in this case the Cuba ransomware campaign. The CTI is provided in the form of technical indicators of compromise (IOCs) as well as MITRE ATT&CK framework tactics and techniques. As a threat intel analyst or responder you can drill down to gather more specific information on Cuba ransomware, such as prevalence and links to other sources of information. You can further drill down to gather more specific actionable intelligence such as indicators of compromise and tactics/techniques aligned to the MITRE ATT&CK framework.
From the McAfee Advanced Threat Research (ATR) blog, you can see that Cuba ransomware leverages tactics and techniques common to other APT campaigns. Currently, the Initial Access vector is not known. It could very well be spear phishing, exploited system tools and signed binaries, or a multitude of other popular methods.
Today’s digital enterprise is a hybrid environment of on-premise systems and cloud services with multiple entry points for attacks like Cuba ransomware. The work from home operating model forced by COVID-19 has only expanded the attack surface and increased risk for successful spear phishing attacks if organizations did not adapt their security posture and increase training for remote workers. Mitigating the risk of attacks like Cuba ransomware requires a security architecture with the right controls at the device, on the network and in security operations (SecOps). The Center for Internet Security (CIS) Top 20 Cyber Security Controls provides a good guide to build that architecture. As indicated earlier, the exact entry vector used by Cuba ransomware is currently unknown, so what follows, here, are more generalized recommendations for protecting your enterprise.
According to Threat Intelligence and Research, the initial access for Cuba ransomware is not currently known. As attackers can leverage many popular techniques for initial access, it is best to validate efficacy on all layers of defenses. This includes user awareness training and response procedures, intelligence and behavior-based malware defenses on email systems, web proxy and endpoint systems, and finally SecOps playbooks for early detection and response against suspicious email attachments or other phishing techniques. The following chart summarizes the controls expected to have the most effect against initial stage techniques and the McAfee solutions to implement those controls where applicable.
| MITRE Tactic | MITRE Techniques | CSC Controls | McAfee Capability |
| Initial Access | Spear Phishing Attachments (T1566.001) |
CSC 7 – Email and Web Browser Protection
CSC 8 – Malware Defenses CSC 17 – User Awareness |
Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection,
Web Gateway (MWG), Advanced Threat Defense, Web Gateway Cloud Service (WGCS) |
| Initial Access | Spear Phishing Link (T1566.002) |
CSC 7 – Email and Web Browser Protection
CSC 8 – Malware Defenses CSC 17 – User Awareness |
Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection,
Web Gateway (MWG), Advanced Threat Defense, Web Gateway Cloud Service (WGCS) |
| Initial Access | Spear Phishing (T1566.003) Service |
CSC 7 – Email and Web Browser Protection
CSC 8 – Malware Defenses CSC 17 – User Awareness |
Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection,
Web Gateway (MWG), Advanced Threat Defense, Web Gateway Cloud Service (WGCS) |
For additional information on how McAfee can protect against suspicious email attachments, review this additional blog post: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/mcafee-protects-against-suspicious-email-attachments/
The exploitation stage is where the attacker gains access to the target system. Protection against Cuba ransomware at this stage is heavily dependent on adaptable anti-malware on both end user devices and servers, restriction of application execution, and security operations tools like endpoint detection and response sensors.
McAfee Endpoint Security 10.7 provides a defense in depth capability, including signatures and threat intelligence, to cover known bad indicators or programs, as well as machine-learning and behavior-based protection to reduce the attack surface against Cuba ransomware and detect new exploitation attack techniques. If the initial entry vector is a weaponized Word document with links to external template files on a remote server, for example, McAfee Threat Prevention and Adaptive Threat Protection modules protect against these techniques.
The following chart summarizes the critical security controls expected to have the most effect against exploitation stage techniques and the McAfee solutions to implement those controls where applicable.
| MITRE Tactic | MITRE Techniques | CSC Controls | McAfee Portfolio Mitigation |
| Execution | User Execution (T1204) |
CSC 5 Secure Configuration
CSC 8 Malware Defenses CSC 17 Security Awareness |
Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control (MAC), Web Gateway and Network Security Platform |
| Execution | Command and Scripting Interpreter (T1059)
|
CSC 5 Secure Configuration
CSC 8 Malware Defenses |
Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control (MAC), MVISION EDR |
| Execution | Shared Modules (T1129) |
CSC 5 Secure Configuration
CSC 8 Malware Defenses |
Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control (MAC) |
| Persistence | Boot or Autologon Execution (T1547) |
CSC 5 Secure Configuration
CSC 8 Malware Defenses |
Endpoint Security Platform 10.7 Threat Prevention, MVISION EDR |
| Defensive Evasion | Template Injection (T1221) |
CSC 5 Secure Configuration
CSC 8 Malware Defenses |
Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, MVISION EDR |
| Defensive Evasion | Signed Binary Proxy Execution (T1218) |
CSC 4 Control Admin Privileges
CSC 5 Secure Configuration CSC 8 Malware Defenses |
Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control, MVISION EDR |
| Defensive Evasion | Deobfuscate/Decode Files or Information (T1027)
|
CSC 5 Secure Configuration
CSC 8 Malware Defenses |
Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, MVISION EDR |
For more information on how McAfee Endpoint Security 10.7 can prevent some of the techniques used in the Cuba ransomware exploit stage, review this additional blog post: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/mcafee-amsi-integration-protects-against-malicious-scripts/
The impact stage is where the attacker encrypts the target system, data and perhaps moves laterally to other systems on the network. Protection at this stage is heavily dependent on adaptable anti-malware on both end user devices and servers, network controls and security operation’s capability to monitor logs for anomalies in privileged access or network traffic. The following chart summarizes the controls expected to have the most effect against impact stage techniques and the McAfee solutions to implement those controls where applicable:
The public leak site of Cuba ransomware can be found via TOR: http://cuba4mp6ximo2zlo[.]onion/
| MITRE Tactic | MITRE Techniques | CSC Controls | McAfee Portfolio Mitigation |
| Discovery | Account Discovery (T1087) |
CSC 4 Control Use of Admin Privileges
CSC 5 Secure Configuration CSC 6 Log Analysis |
MVISION EDR, MVISION Cloud, Cloud Workload Protection |
| Discovery | System Information Discovery (T1082) |
CSC 4 Control Use of Admin Privileges
CSC 5 Secure Configuration CSC 6 Log Analysis |
MVISION EDR, MVISION Cloud, Cloud Workload Protection |
| Discovery | System Owner/User Discovery (T1033) |
CSC 4 Control Use of Admin Privileges
CSC 5 Secure Configuration CSC 6 Log Analysis |
MVISION EDR, MVISION Cloud, Cloud Workload Protection |
| Command and Control | Encrypted Channel (T1573) |
CSC 8 Malware Defenses
CSC 12 Boundary Defenses |
Web Gateway, Network Security Platform |
As a threat intel analyst or hunter, you might want to quickly scan your systems for any indicators you received on Cuba ransomware. Of course, you can do that manually by downloading a list of indicators and searching with available tools. However, if you have MVISION EDR and Insights, you can do that right from the console, saving precious time. Hunting the attacker can be a game of inches so every second counts. Of course, if you found infected systems or systems with indicators, you can take action to contain and start an investigation for incident response immediately from the MVISION EDR console.
In addition to these IOCs, YARA rules are available in our technical analysis of Cuba ransomware.
Files:
151.bat
151.ps1
Kurva.ps1
Email addresses:
under_amur@protonmail[.]ch
helpadmin2@cock[.]li
helpadmin2@protonmail[.]com
iracomp2@protonmail[.]ch
fedelsupportagent@cock.li
admin@cuba-supp.com
cuba_support@exploit.im
Domain:
kurvalarva[.]com
Script for lateral movement and deployment:
54627975c0befee0075d6da1a53af9403f047d9e367389e48ae0d25c2a7154bc
c385ef710cbdd8ba7759e084051f5742b6fa8a6b65340a9795f48d0a425fec61
40101fb3629cdb7d53c3af19dea2b6245a8d8aa9f28febd052bb9d792cfbefa6
Cuba Ransomware:
c4b1f4e1ac9a28cc9e50195b29dde8bd54527abc7f4d16899f9f8315c852afd4
944ee8789cc929d2efda5790669e5266fe80910cabf1050cbb3e57dc62de2040
78ce13d09d828fc8b06cf55f8247bac07379d0c8b8c8b1a6996c29163fa4b659
33352a38454cfc247bc7465bf177f5f97d7fd0bd220103d4422c8ec45b4d3d0e
672fb249e520f4496e72021f887f8bb86fec5604317d8af3f0800d49aa157be1
e942a8bcb3d4a6f6df6a6522e4d5c58d25cdbe369ecda1356a66dacbd3945d30
907f42a79192a016154f11927fbb1e6f661f679d68947bddc714f5acc4aa66eb
28140885cf794ffef27f5673ca64bd680fc0b8a469453d0310aea439f7e04e64
271ef3c1d022829f0b15f2471d05a28d4786abafd0a9e1e742bde3f6b36872ad
6396ea2ef48aa3d3a61fb2e1ca50ac3711c376ec2b67dbaf64eeba49f5dfa9df
bda4bddcbd140e4012bab453e28a4fba86f16ac8983d7db391043eab627e9fa1
7a17f344d916f7f0272b9480336fb05d33147b8be2e71c3261ea30a32d73fecb
c206593d626e1f8b9c5d15b9b5ec16a298890e8bae61a232c2104cbac8d51bdd
9882c2f5a95d7680626470f6c0d3609c7590eb552065f81ab41ffe074ea74e82
c385ef710cbdd8ba7759e084051f5742b6fa8a6b65340a9795f48d0a425fec61
54627975c0befee0075d6da1a53af9403f047d9e367389e48ae0d25c2a7154bc
1f825ef9ff3e0bb80b7076ef19b837e927efea9db123d3b2b8ec15c8510da647
40101fb3629cdb7d53c3af19dea2b6245a8d8aa9f28febd052bb9d792cfbefa6
00ddbe28a31cc91bd7b1989a9bebd43c4b5565aa0a9ed4e0ca2a5cfb290475ed
729950ce621a4bc6579957eabb3d1668498c805738ee5e83b74d5edaf2f4cb9e
| Tactic | Technique | Observable | IOCs |
| Execution | Command and Scripting Interpreter: PowerShell (T1059.001) | Cuba team is using PowerShell payload to drop Cuba ransomware | f739977004981fbe4a54bc68be18ea79
68a99624f98b8cd956108fedcc44e07c bdeb5acc7b569c783f81499f400b2745
|
| Execution | System Services: Service Execution (T1569.002) |
|
|
| Execution | Shared Modules (T1129) | Cuba ransomware links function at runtime | Functions:
“GetModuleHandle” “GetProcAddress” “GetModuleHandleEx” |
| Execution | Command and Scripting Interpreter (T1059) | Cuba ransomware accepts command line arguments | Functions:
“GetCommandLine” |
| Persistence | Create or Modify System Process: Windows Service (T1543.003) | Cuba ransomware can modify services | Functions:
“OpenService” “ChangeServiceConfig” |
| Privilege Escalation | Access Token Manipulation (T1134) | Cuba ransomware can adjust access privileges | Functions:
“SeDebugPrivilege” “AdjustTokenPrivileges” “LookupPrivilegeValue” |
| Defense Evasion | File and Directory Permissions Modification (T1222) | Cuba ransomware will set file attributes | Functions:
“SetFileAttributes” |
| Defense Evasion | Obfuscated files or Information (T1027) | Cuba ransomware is using xor algorithm to encode data | |
| Defense Evasion | Virtualization/Sandbox Evasion: System Checks | Cuba ransomware executes anti-vm instructions | |
| Discovery | File and Directory Discovery (T1083) | Cuba ransomware enumerates files | Functions:
“FindFirstFile” “FindNextFile” “FindClose” “FindFirstFileEx” “FindNextFileEx” “GetFileSizeEx” |
| Discovery | Process Discovery (T1057) | Cuba ransomware enumerates process modules | Functions:
“K32EnumProcesses” |
| Discovery | System Information Discovery (T1082) | Cuba ransomware can get keyboard layout, enumerates disks, etc | Functions:
“GetKeyboardLayoutList” “FindFirstVolume” “FindNextVolume” “GetVolumePathNamesForVolumeName” “GetDriveType” “GetLogicalDriveStrings” “GetDiskFreeSpaceEx” |
| Discovery | System Service Discovery (T1007) | Cuba ransomware can query service status | Functions:
“QueryServiceStatusEx” |
| Collection | Input Capture: Keylogging (T1056.001) | Cuba ransomware logs keystrokes via polling | Functions:
“GetKeyState” “VkKeyScan” |
| Impact | Service Stop (T1489) | Cuba ransomware can stop services | |
| Impact | Data encrypted for Impact (T1486) | Cuba ransomware encrypts data |
Many of the exploit stage techniques in this attack could use legitimate Windows processes and applications to either exploit or avoid detection. We discussed, above, how the Endpoint Protection Platform can disrupt weaponized documents but, by using MVISION EDR, you can get more visibility. As security analysts, we want to focus on suspicious techniques used by Initial Access, as this attack’s Initial Access is unknown.
Events from McAfee Endpoint Protection and McAfee MVISION EDR play a key role in Cuba ransomware incident and threat response. McAfee ePO centralizes event collection from all managed endpoint systems. As a threat responder, you may want to create a dashboard for Cuba ransomware-related threat events to understand your current exposure.
To defeat targeted threat campaigns, defenders must collaborate internally and externally to build an adaptive security architecture which will make it harder for threat actors to succeed and build resilience in the business. This blog highlights how to use McAfee’s security solutions to prevent, detect and respond to Cuba ransomware and attackers using similar techniques.
McAfee ATR is actively monitoring this campaign and will continue to update McAfee Insights and its social networking channels with new and current information. Want to stay ahead of the adversaries? Check out McAfee Insights for more information.
The post McAfee Defender’s Blog: Cuba Ransomware Campaign appeared first on McAfee Blogs.
Ever since I started working in IT Security more than 10 years ago, I wondered, what helps defend against malware the best?
This simple question does not stand on its own, as there are several follow-up questions to that:
This blog will guide you through my research and thought process around these questions and how you can enable yourself to answer these for your own organization!
As mentioned above, the central question “what helps best?” has followed me throughout the years, but my methods to be able to answer this question have evolved. The first interaction I had with IT Security was more than 10 years ago, where I had to manually deploy new Anti-Virus software from a USB-key to around 100 devices. The settings were configured by a colleague in our IT-Team, and my job was to help remove infections when they came up, usually by going through the various folders or registry keys and cleaning up the remains. The most common malware was Adware, and the good-ol obnoxious hotbars which were added to the browser. I remember one colleague calling into IT saying “my internet has become so small, I can barely even read 5 lines of text” which we later translated into “I had 6 hotbars installed on my Internet Explorer so there was nearly no space left for the content to be displayed”.
Exemplary picture of the “internet” getting smaller.
Jump ahead a couple of years, I started working with McAfee ePolicy Orchestrator to manage and deploy Anti-Malware from a central place automatically, and not just for our own IT, but I was was allowed to implement McAfee ePO into our customers’ environments. This greatly expanded my view into what happens in the world of malware and I started using the central reporting tool to figure out where all these threats were coming from:
Also, I was able to understand how the different McAfee tools helped me in detecting and blocking these threats:
But this only showed the viewpoint of one customer and I had to manually overlay them to figure out what defense mechanism worked best. Additionally, I couldn’t see what was missed by the defense mechanisms, either due to configuration, missing signatures, or disabled modules. So, these reports gave me a good viewpoint into the customers I managed, but not the complete picture. I needed a different perspective, perhaps from other customers, other tools, or even other geo-locations.
Let us jump further ahead in my personal IT security timeline to about June 2020:
As you could see above, I spent quite a lot of time optimizing setups and configurations to assist customers in increasing their endpoint security. As time progressed, it became clear that solely using Endpoint Protection, especially only based on signatures, was not state of the art. Protection needs to be a combination of security controls rather than the obnoxious silver bullet that is well overplayed in cybersecurity. And still, the best product or solution set doesn’t help if you don’t know what you are looking for (Question 1&2), how to prepare (Question 4) or if you misconfigured the product including all subfolders of “C:\” as an exclusion for On-Access-Scanning (Question 5).
Then McAfee released MVISION Insights this summer and it clicked in my head:
Framework I could also link from the threat to defensive capabilitiesWith this data available it was possible to create a heatmap not just by geo-location or a very high number of new threats every day, hour or even minute, but on how specific types of campaigns are operating out in the wild. To start assessing the data, I took 60 ransomware campaigns dating between January and June 2020 and pulled out all the MITRE ATT&CK© techniques that have been used and displayed them on a heatmap:
Amber/Orange: Being used the most, green: only used in 1 or 2 campaigns
Reality Check 1: Does this mapping look accurate?
For me it does, and here is why:
Next, we need to understand what can be done to detect and ideally block ransomware in its tracks. For this I summarized key malware defense capabilities and mapped them to the tactics being used most:
| MITRE Tactic | Security Capability | Example McAfee solution features |
| Execution | Attack surface reduction | ENS Access Protection and Exploit Prevention, MVISION Insights recommendations |
| Multi-layered detection | ENS Exploit Prevention, MVISION Insights telemetry, MVISION EDR Tracing, ATD file analysis | |
| Multi-layered protection | ENS On-Access-Scanning using Signatures, GTI, Machine-Learning and more | |
| Rule & Risk-based analytics | MVISION EDR tracing | |
| Containment | ENS Dynamic Application Containment | |
| Persistence | Attack surface reduction | ENS Access Protection or Exploit Prevention, MVISION Insights recommendations |
| Multi-layered detection | ENS Exploit Prevention, MVISION Insights telemetry, MVISION EDR Tracing, ATD file analysis | |
| Sandboxing and threat analysis | ATD file analysis | |
| Rule & Risk-based analytics | MVISION EDR tracing | |
| Containment | ENS Dynamic Application Containment | |
| Defense Evasion | Attack surface reduction | ENS Access Protection and Exploit Prevention, MVISION Insights recommendations |
| Multi-layered detection | ENS Exploit Prevention, MVISION Insights telemetry, MVISION EDR Tracing, ATD file analysis | |
| Sandboxing and threat analysis | ATD file analysis | |
| Rule & Risk-based analytics | MVISION EDR tracing | |
| Containment | ENS Dynamic Application Containment | |
| Discovery | Attack surface reduction | ENS Access Protection and Exploit Prevention |
| Multi-layered detection | ENS Exploit Prevention, MVISION EDR Tracing, ATD file analysis | |
| Sandboxing and threat analysis | ATD file analysis | |
| Rule & Risk-based analytics | MVISION EDR tracing | |
| Command & Control | Attack surface reduction | MVISION Insights recommendations |
| Multi-layered detection | ENS Firewall IP Reputation, MVISION Insights telemetry, MVISION EDR Tracing, ATD file analysis | |
| Multi-layered protection | ENS Firewall | |
| Rule & Risk-based analytics | MVISION EDR tracing | |
| Containment | ENS Firewall and Dynamic Application Containment | |
| Impact | Multi-layered detection | MVISION EDR tracing, ATD file analysis |
| Rule & Risk-based analytics | MVISION EDR tracing | |
| Containment | ENS Dynamic Application Containment | |
| Advanced remediation | ENS Advanced Rollback |
A description of the McAfee Solutions is provided below.
Now this allowed me to map the solutions from the McAfee portfolio to each capability, and with that indirectly to the MITRE tactics. But I did not want to end here, as different tools might take a different role in the defensive architecture. For example, MVISION Insights can give you details around your current configuration and automatically overlays it with the current threat campaigns in the wild, giving you the ability to proactively prepare and harden your systems. Another example would be using McAfee Endpoint Security (ENS) to block all unsigned PowerShell scripts, effectively reducing the risk of being hit by a file-less malware based on this technology to nearly 0%. On the other end of the scale, solutions like MVISION EDR will give you great visibility of actions that have occurred, but this happens after the fact, so there is a high chance that you will have some cleaning up to do. This brings me to the topic of “improving protection before moving into detection” but this is for another blog post.
Coming back to the mapping shown above, let us quickly do…
Reality Check 2: Does this mapping feel accurate too?
For me it does, and here is why:
Now with all this data at hand we can come to the final step and bring it all together in one simple graph.
Before we jump into our conclusion, here is a quick summary of the actions I have taken:
So, without further ado and with a short drumroll I want to present to you the McAfee security architecture that best defends against current malware campaigns:
For reference, here is a quick breakdown of the components that make up the architecture above:
MVISION ePO is the SaaS-based version of our famous security management solution, which makes it possible to manage a heterogenous set of systems, policies, and events from a central place. Even though I have mentioned the SaaS-based version here, the same is true for our ePO on-premises software as well.
MVISION Insights is a key data source that helps organizations understand what campaigns and threats are trending. This is based on research from our Advanced Threat Research (ATR) team who use our telemetry data inside our Global Threat Intelligence (GTI) big-data platform to enhance the details that are provided.
MVISION Endpoint Detect & Response (EDR) is present in multiple boxes here, as it is a sensor on one side, which sits on the endpoint and collects data, and it is also a cloud service which receives, stores and analyses the data.
EPP is our Endpoint Protection Platform, which contains multiple items working in conjunction. First there is McAfee Endpoint Security (ENS) that is sitting on the device itself and has multiple detection and protection capabilities. For me, the McAfee Threat Intelligence Exchange (TIE) server is always a critical piece to McAfee’s Endpoint Protection Platform and has evolved from a standalone feature to an integrated building block inside ePO and is therefore not shown in the graphic above.
McAfee Advanced Threat Defense (ATD) extends the capabilities of both EPP and EDR, as it can run suspicious files in a separated environment and shares the information gathered with the other components of the McAfee architecture and even 3rd-party tools. It also goes the other way around as ATD allows other security controls to forward files for analysis in our sandbox, but this might be a topic for another blog post.
All the items listed above can be acquired by licensing our MVISION Premium suite in combination with McAfee ATD.
Based on the components and the mapping to the capabilities, I was also able to create a graph based on our most common device security bundles and their respective malware defense score:
In the graph above you can see four of our most sold bundles, ranging from the basic MVISION Standard, up to MVISION Premium in combination with McAfee Advanced Threat Defense (ATD). The line shows the ransomware detection & protection score, steadily rising as you go from left to right. Interestingly, the cost per point, i.e. how much dollar you need to spend to get one point, is much lower when buying the largest option in comparison to the smaller ones. As the absolute cost varies on too many variables, I have omitted an example here. Contact your local sales representative to gather an estimated calculation for your environment.
So, have I come to this conclusion by accident? Let us find out in the last installment of the reality check:
Reality Check 3: Is this security architecture well suited for today’s threats?
For me it does, and here is why:
While writing up my thoughts into the blog post, I was reminded of the “Hitchhikers Guide to the Galaxy”, as my journey in cybersecurity started out with the search for the answer to everything. But over the years it evolved into the multiple questions I prompted at the start of the article:
And certainly, the answers to these questions are a moving target. Not only do the tools and techniques by the adversaries evolve, so do all the capabilities on the defensive side.
I welcome you to take the information provided by my research and apply it to your own security architecture:
Thank you for reading this blog post and following my train of thought. I would love to hear back from you, on how you assess yourself, what could be the next focus area for my research or if you want to apply the scoring mechanism on your environment! So please find me on LinkedIn or Twitter, write me a short message or just say “Hi!”.
I also must send out a big “THANK YOU!” to all my colleagues at McAfee helping out during my research: Mo Cashman, Christian Heinrichs, John Fokker, Arnab Roy, James Halls and all the others!
The post McAfee Defenders Blog: Reality Check for your Defenses appeared first on McAfee Blogs.
The McAfee Labs Advanced Threat Research team is committed to uncovering security issues in both software and hardware to help developers provide safer products for businesses and consumers. We recently investigated software installed on computers used in K-12 school districts. The focus of this blog is on Netop Vision Pro produced by Netop. Our research into this software led to the discovery of four previously unreported critical issues, identified by CVE-2021-27192, CVE-2021-27193, CVE-2021-27194 and CVE-2021-27195. These findings allow for elevation of privileges and ultimately remote code execution, which could be used by a malicious attacker, within the same network, to gain full control over students’ computers. We reported this research to Netop on December 11, 2020 and we were thrilled that Netop was able to deliver an updated version in February of 2021, effectively patching many of the critical vulnerabilities.
Netop Vision Pro is a student monitoring system for teachers to facilitate student learning while using school computers. Netop Vision Pro allows teachers to perform tasks remotely on the students’ computers, such as locking their computers, blocking web access, remotely controlling their desktops, running applications, and sharing documents. Netop Vision Pro is mainly used to manage a classroom or a computer lab in a K-12 environment and is not primarily targeted for eLearning or personal devices. In other words, the Netop Vision Pro Software should never be accessible from the internet in the standard configuration. However, as a result of these abnormal times, computers are being loaned to students to continue distance learning, resulting in schooling software being connected to a wide array of networks increasing the attack surface.
Netop provides all software as a free trial on its website, which makes it easy for anyone to download and analyze it. Within a few minutes of downloading the software, we were able to have it configured and running without any complications.
We began by setting up the Netop software in a normal configuration and environment. We placed four virtual machines on a local network; three were set up as students and one was set up as a teacher. The three student machines were configured with non-administrator accounts in our attempt to emulate a normal installation. The teacher first creates a “classroom” which then can choose which student PCs should connect. The teacher has full control and gets to choose which “classroom” the student connects to without the student’s input. Once a classroom has been setup, the teacher can start a class which kicks off the session by pinging each student to connect to the classroom. The students have no input if they want to connect or not as it is enforced by the teacher. Once the students have connected to the classroom the teacher can perform a handful of actions to the entire class or individual students.
During this setup we also took note of the permission levels of each component. The student installation needs to be tamperproof and persistent to prevent students from disabling the service. This is achieved by installing the Netop agent as a system service that is automatically started at boot. The teacher install executes as a normal user and does not start at boot. This difference in execution context and start up behavior led us to target the student installs, as an attacker would have a higher chance of gaining elevated system permissions if it was compromised. Additionally, the ratio of students to teachers in a normal school environment would ensure any vulnerabilities found on the student machines would be wider spread.
With the initial install complete, we took a network capture on the local network and took note of the traffic between the teacher and student. An overview of the first few network packets can been seen in Figure 1 below and how the teacher, student transaction begins.
Figure 1: Captured network traffic between teacher and student
Our first observation, now classified as CVE-2021-27194, was that all network traffic was unencrypted with no option to turn encryption on during configuration. We noticed that even information normally considered sensitive, such as Windows credentials (Figure 2) and screenshots (Figure 4), were all sent in plaintext. Windows credentials were observed on the network when a teacher would issue a “Log on” command to the student. This could be used by the teacher or admin to install software or simply help a student log in.
Figure 2: Windows credentials passed in plaintext
Additionally, we observed interesting default behavior where a student connecting to a classroom immediately began to send screen captures to the classroom’s teacher. This allows the teacher to monitor all the students in real time, as shown in Figure 3.
Figure 3: Teacher viewing all student machines via screenshots
Since there is no encryption, these images were sent in the clear. Anyone on the local network could eavesdrop on these images and view the contents of the students’ screens remotely. A new screenshot was sent every few seconds, providing the teacher and any eavesdroppers a near-real time stream of each student’s computer. To capture and view these images, all we had to do was set our network card to promiscuous mode (https://www.computertechreviews.com/definition/promiscuous-mode/) and use a tool like Driftnet (https://github.com/deiv/driftnet). These two steps allowed us to capture the images passed over the network and view every student screen while they were connected to a classroom. The image in Figure 4 is showing a screenshot captured from Driftnet. This led us to file our first vulnerability disclosed as CVE-2021-27194, referencing “CWE-319: Cleartext Transmission of Sensitive Information” for this finding. As pointed out earlier, the teacher and the student clients will communicate directly over the local network. The only way an eavesdropper could access the unencrypted data would be by sniffing the traffic on the same local network as the students.
Figure 4: Image of student’s desktop captured from Driftnet over the network
With the goal of remote code execution on the students’ computers, we began to dissect the first network packet, which the teacher sends to the students, telling them to connect to the classroom. This was a UDP message sent from the teacher to all the students and can be seen in Figure 5.
Figure 5: Wireshark capture of teacher’s UDP message
The purpose of this packet is to let the student client software know where to find the teacher computer on the network. Because this UDP message is sent to all students in a broadcast style and requires no handshake or setup like TCP, this was a good place to start poking at.
We created a custom Scapy layer (https://scapy.readthedocs.io/en/latest/api/scapy.layers.html) (Figure 6) from the UDP message seen in Figure 5 to begin dissecting each field and crafting our own packets. After a few days of fuzzing with UDP packets, we were able to identify two things. First, we observed a lack of length checks on strings and second, random values sent by the fuzzer were being written directly to the Windows registry. The effect of these tests can easily be seen in Figure 7.
Figure 6: UDP broadcast message from teacher
Even with these malformed entries in the registry (Figure 7) we never observed the application crashing or responding unexpectedly. This means that even though the application wasn’t handling our mutated packet properly, we never overwrote anything of importance or crossed a string buffer boundary.
Figure 7: Un-sanitized characters being written to the Registry
To go further we needed to send the next few packets that we observed from our network capture (Figure 8). After the first UDP message, all subsequent packets were TCP. The TCP messages would negotiate a connection between the student and the teacher and would keep the socket open for the duration of the classroom connection. This TCP negotiation exchange was a transfer of 11 packets, which we will call the handshake.
Figure 8: Wireshark capture of a teacher starting class
To respond appropriately to the TCP connection request, we needed to emulate how a valid teacher would respond to the handshake; otherwise, the student would drop the connection. We began reverse engineering the TCP network traffic and attempted to emulate actual “teacher” traffic. After capturing a handful of packets, the payloads started to conform to roughly the same format. Each started with the size of the packet and the string “T125”. There were three packets in the handshake that contained fields that were changing between each classroom connection. In total, four changing fields were identified.
The first field was the session_id, which we identified in IDA and is shown in the UDP packet from Figure 6. From our fuzzing exercise with the UDP packet, we learned if the same session_id was reused multiple times, the student would still respond normally, even though the actual network traffic we captured would often have a unique session_id.
This left us three remaining dynamic fields which we identified as a teacher token, student token, and a unique unknown DWORD (8 bytes). We identified two of these fields by setting up multiple classrooms with different teacher and student computers and monitoring these values. The teacher token was static and unique to each teacher. We discovered the same was true with the student token. This left us with the unique DWORD field that was dynamic in each handshake. This last field at first seemed random but was always in the same relative range. We labeled this as “Token3” for much of our research, as seen in Figure 9 below.
Figure 9: Python script output identifying “Token3”
Eventually, while using WinDbg to perform dynamic analysis, the value of Token3 started to look familiar. We noticed it matched the range of memory being allocated for the heap. This can be seen in Figure 10.
Figure 10: WinDbg address space analysis from a student PC
By combining our previous understanding of the UDP broadcast traffic with our ability to respond appropriately to the TCP packets with dynamic fields, we were able to successfully emulate a teacher’s workstation. We demonstrated this by modifying our Python script with this new information and sending a request to connect with the student. When a student connects to a teacher it displays a message indicating a successful connection has been made. Below are two images showing a teacher connecting (Figure 11) and our Python script connecting (Figure 12). Purely for demonstration purposes, we have named our attack machine “hacker”, and our classroom “hacker-room.”
Figure 11: Emulation of a teacher successful
Figure 12: Emulated teacher connection from Python script
To understand the process of reverse engineering the network traffic in more detail, McAfee researchers Douglas McKee and Ismael Valenzuela have released an in-depth talk on how to hack proprietary protocols like the one used by Netop. Their webinar goes into far more detail than this blog and can be viewed here.
Since we have successfully emulated a teacher’s connection using Python, for clarity we will refer to ourselves as the attacker and a legitimate connection made through Netop as the teacher.
Next, we began to look at some of the actions that teachers can perform and how we could take advantage of them. One of the actions that a teacher can perform is starting applications on the remote students’ PCs. In the teacher suite, the teacher is prompted with the familiar Windows Run prompt, and any applications or commands set to run are executed on the student machines (Figure 13).
Figure 13: The teacher “Run Application” prompt
Looking at the network traffic (shown in Figure 14), we were hoping to find a field in the packet that could allow us to deviate from what was possible using the teacher client. As we mentioned earlier, everything is in plaintext, making it quite easy to identify which packets were being sent to execute applications on the remote systems by searching within Wireshark.
Figure 14: Run “calc” packet
Before we started to modify the packet that runs applications on the student machines, we first wanted to see if we could replay this traffic successfully. As you can see in the video below, our Python script was able to run PowerShell followed by Windows Calculator on each of the student endpoints. This is showcasing that even valid teacher actions can still be useful to attackers.
The ability for an attacker to emulate a teacher and execute arbitrary commands on the students’ machines brings us to our second CVE. CVE-2021-27195 was filed for “CWE-863: Incorrect Authorization” since we were able to replay modified local network traffic.
When the teacher sends a command to the student, the client would drop privileges to that of the logged-in student and not keep the original System privileges. This meant that if an attacker wanted unrestricted access to the remote system, they could not simply replay normal traffic, but instead would have to modify each field in the traffic and observe the results.
In an attempt to find a way around the privilege reduction during command execution, we continued fuzzing all fields located within the “run command” packet. This proved unsuccessful as we were unable to find a packet structure that would prevent the command from lowering privileges. This required a deeper dive into the code in handling the remote command execution processed on the student endpoint. By tracing the execution path within IDA, we discovered there was in fact a path that allows remote commands to execute without dropping privileges, but it required a special case, as shown in Figure 15.
Figure 15: IDA graph view showing alternate paths of code execution
Figure 16: Zoomed in image of the ShellExecute code path
The code path that bypasses the privilege reduction and goes directly to “ShellExecute” was checking a variable that had its value set during startup. We were not able to find any other code paths that updated this value after the software started. Our theory is this value may be used during installation or uninstallation, but we were not able to legitimately force execution to the “ShellExecute” path.
This code path to “ShellExecute” made us wonder if there were other similar branches like this that could be reached. We began searching the disassembled code in IDA for calls not wrapped with code resulting in lower privileges. We found four cases where the privileges were not reduced, however none of them were accessible over the network. Regardless, they still could potentially be useful, so we investigated each. The first one was used when opening Internet Explorer (IE) with a prefilled URL. This turned out to be related to the support system. Examining the user interface on the student machine, we discovered a “Technical Support” button which was found in the Netop “about” menu.
When the user clicks on the support button, it opens IE directly into a support web form. The issue, however, is privileges are never dropped, resulting in the IE process being run as System because the Netop student client is also run as System. This can be seen in Figure 11. We filed this issue as our third CVE, CVE-2021-27192 referencing “CWE-269: Incorrect Privilege Assignment”.
Figure 17: Internet Explorer running as System
There are a handful of well-documented ways to get a local elevation of privilege (LPE) using only the mouse when the user has access to an application running with higher privileges. We used an old technique which uses the “Save as” button to navigate to the folder where cmd.exe is located and execute it. The resulting CMD process inherits the System privileges of the parent process, giving the user a System-level shell.
While this LPE was exciting, we still wanted to find something with a remote attack vector and utilize our Python script to emulate teacher traffic. We decided to take a deeper dive into the network traffic to see what we could find. Simulating an attacker, we successfully emulated the following:
During the emulation of all the above actions we performed some rudimentary fuzzing on various fields of each and discovered six crashes which caused the Netop student install to crash and restart. We were able to find two execution violations, two read violations, one write exception, and one kernel exception. After investigation, we determined these crashes were not easily exploitable and therefore a lower priority for deeper investigation. Regardless, we reported them to Netop along with all other findings.
Netop Vision Pro comes with a handful of plugins installed by default, which are used to separate different functionality from the main Netop executable. For example, to enable the ability for the teacher and student to instant message (IM) each other, the MChat.exe plugin is used. With a similar paradigm to the main executable, the students should not be able to stop these plugins, so they too run as System, making them worth exploring.
Mimicking our previous approach, we started to look for “ShellExecute” calls within the plugins and eventually discovered three more privilege escalations, each of which were conducted in a comparable way using only the mouse and bypassing restrictive file filters within the “Save as” windows. The MChat.exe, SSView.exe (Screen Shot Viewer), and the About page’s “System Information” windows all had a similar “Save as” button, each resulting in simple LPEs with no code or exploit required. We added each of these plugins under the affected versions field on our third CVE, CVE-2021-27192, mentioned above.
We were still searching for a method to achieve remote code execution and none of the “ShellExecute” calls used for the LPEs were accessible over the network. We started to narrow down the plugins that pass user supplied data over the network. This directed our attention back to the MChat plugin. As part of our initial recon for research projects, we reviewed change logs looking for any relevant security changes. During this review we noted an interesting log pertaining to the MChat client as seen in Figure 13.
Figure 18: Change log from Netop.com
The Chat function runs as System, like all the plugins, and can send text or files to the remote student computer. An attacker can always use this functionality to their advantage by either overwriting existing files or enticing a victim to click on a dropped executable. Investigating how the chat function works and specifically how files are sent, we discovered that the files are pushed to the student computers without any user interaction from the student. Any files pushed by a teacher are stored in a “work directory”, which the student can open from the IM window. Prior to the latest release it would have been opened as System; this was fixed as referenced in Figure 18. Delving deeper into the functionality of the chat application, we found that the teacher also has the ability to read files in the student’s “work directory” and delete files within it. Due to our findings demonstrated with CVE-2021-27195, we can leverage our emulation code as an attacker to write, read, and delete files within this “work directory” from a remote attack vector on the same local network. This ability to read and write files accounted for the last CVE that we filed, CVE-2021-27193 referencing “CWE-276: Incorrect Default Permissions,” with the overall highest CVSS score of 9.5.
In order to determine if the MChat plugin would potentially give us System-level access, we needed to investigate if the plugin’s file operations were restricted to the student’s permissions or if the plugin inherited the System privileges from the running context. Examining the disassembled code of the MChat plugin, as displayed in Figure 14, we learned that all file actions on the student computer are executed with System privileges. Only after the file operation finishes will the permissions be set to allow access for everyone, essentially the effect of using the Linux “chmod 777” command, to make the files universally read/writable.
Figure 19: IDA screenshot of MChat file operations changing access to everyone
To validate this, we created several test files using an admin account and restricted the permissions to disallow the student from modifying or reading the test files. We proceeded to load the teacher suite, and through an MChat session confirmed we were able to read, write, and delete these files. This was an exciting discovery; however, if the attacker is limited to the predetermined “work directory” they would be limited in the effect they could have on the remote target. To investigate if we could change the “work directory” we began digging around in the teacher suite. Hidden in a few layers of menus (Figure 20) we found that a teacher can indeed set the remote student’s “work directory” and update this remotely. Knowing we can easily emulate any teacher’s command means that we could modify the “work directory” anywhere on the student system. Based on this, an attacker leveraging this flaw could have System access to modify any file on the remote PC.
Figure 20: Changing the remote student path from a teacher’s client
Now that we knew that the teacher could overwrite any file on the system, including system executables, we wanted to automate this attack and add it to our Python script. By automating this we want to showcase how attackers can use issues like this to create tools and scripts that have real world impacts. For a chat session to begin, we had to initiate the 11-packet handshake we previously discussed. Once the student connected to our attack machine, we needed to send a request to start a chat session with the target student. This request would make the student respond using TCP, yet this time, on a separate port, initiating an MChat seven-packet handshake. This required us to reverse engineer this new handshake format in a similar approach as described earlier. Unlike the first handshake, the MChat handshake had a single unique identifier for each session, and after testing, it was determined that the ID could be hardcoded with a static value without any negative effects.
Finally, we wanted to overwrite a file that we could ensure would be executed with System privileges. With the successful MChat handshake complete we needed to send a packet that would change the “work directory” to that of our choosing. Figure 21 shows the packet as a Scapy layer used to change the work directory on the student’s PC. The Netop plugin directory was a perfect target directory to change to since anything executed from this directory would be executed as System.
Figure 21: Change working directory on the student PC
The last step in gaining System-level execution was to overwrite and execute one of the plugins with a “malicious” binary. Through testing we discovered that if the file already exists in the same directory, the chat application is smart enough to not overwrite it, but instead adds a number to the filename. This is not what we wanted since the original plugin would get executed instead of our “malicious” one. This meant that we had to also reverse engineer a packet containing commands that are used to delete files. The Scapy layer used to delete a file and save a new one is shown in Figure 22.
Figure 22: Python Scapy layers to “delete” (MChatPktDeleteFile) and “write” (MChatPkt6) files
With these Scapy layers we were able to replace the target plugin with a binary of our choosing, keeping the same name as the original plugin. We chose the “SSView.exe” plugin, which is a plugin used to show screenshots on the student’s computer. To help visualize this entire process please reference Figure 23.
Figure 23: An attack flow using the MChat plugin to overwrite an executable
Now that the SSView.exe plugin has been overwritten, triggering this plugin will execute our attacker-supplied code. This execution will inherit the Netop System privileges, and all can be conducted from an unauthenticated remote attack vector.
It is not hard to imagine a scenario where a culmination of these issues can lead to several negative outcomes. The largest impact being remote code execution of arbitrary code with System privileges from any device on the local network. This scenario has the potential to be wormable, meaning that the arbitrary binary that we run could be designed to seek out other devices and further the spread. In addition, if the “Open Enrollment” option for a classroom is configured, the Netop Vision Pro student client broadcasts its presence on the network every few seconds. This can be used to an attacker’s advantage to determine the IP addresses of all the students connected on the local network. As seen in Figure 24, our Python script sniffed for student broadcast messages for 5 seconds and found all three student computers on the same network. Because these broadcast messages are sent out to the entire local network, this could very well scale to an entire school system.
Figure 24: Finding all students on the local network.
With a list of computers running the student software, an attacker can then issue commands to each one individually to run arbitrary code with System privileges. In the context of hybrid and e-learning it is important to remember that this software on the student’s computer doesn’t get turned off. Because it is always running, even when not in use, this software assumes every network the device connects to could have a teacher on it and begins broadcasting its presence. An attacker doesn’t have to compromise the school network; all they need is to find any network where this software is accessible, such as a library, coffee shop, or home network. It doesn’t matter where one of these student’s PCs gets compromised as a well-designed malware could lay dormant and scan each network the infected PC connects to, until it finds other vulnerable instances of Netop Vision Pro to further propagate the infection.
Once these machines have been compromised the remote attacker has full control of the system since they inherit the System privileges. Nothing at this point could stop an attacker running as System from accessing any files, terminating any process, or reaping havoc on the compromised machine. To elaborate on the effects of these issues we can propose a few scenarios. An attacker could use the discoverability of these machines to deploy ransomware to all the school computers on the network, bringing the school or entire school district to a standstill. A stealthier attacker could silently install keylogging software and monitor screenshots of the students which could lead to social media or financial accounts being compromised. Lastly, an attacker could monitor webcams of the students, bridging the gap from compromised software to the physical realm. As a proof of concept, the video below will show how an attacker can put CVE-2021-27195 and CVE-2021-27193 together to find, exploit, and monitor the webcams of each computer running Netop Vision Pro.
Secure adaptation of software is much easier to achieve when security is baked in from the beginning, rather than an afterthought. It is easy to recognize when software is built for “safe” environments. While Netop Vision Pro was never intended to be internet-facing or be brought off a managed school network, it is still important to implement basic security features like encryption. While designing software one should not assume what will be commonplace in the future. For instance, when this software was originally developed the concept of remote learning or hybrid learning was a far-out idea but now seems like it will be a norm. When security decisions are integrated from inception, software can adapt to new environments while keeping users better protected from future threats.
We disclosed all these findings to Netop on December 11, 2020 and heard back from them shortly after. Our disclosure included recommendations for implementing encryption of all network traffic, adding authentication, and verification of teachers to students, and more precise packet parsing filters. In Netop Vision Pro 9.7.2, released in late February, Netop has fixed the local privilege escalations, encrypted formerly plaintext Windows credentials, and mitigated the arbitrary read/writes on the remote filesystem within the MChat client. The local privilege escalations were fixed by running all plugins as the student and no longer as System. This way, the “Save as” buttons are limited to the student’s account. The Windows credentials are now encrypted using RC4 before being sent over the network, preventing eavesdroppers from gathering account credentials. Lastly, since all the plugins are running as the student, the MChat client can no longer delete and replace system executables which successfully mitigates the attack shown in the impact section. The network traffic is still unencrypted, including the screenshots of the student computers but Netop has assured us it is working on implementing encryption on all network traffic for a future update. We’d like to recognize Netop’s outstanding response and rapid development and release of a more secure software version and encourage industry vendors to take note of this as a standard for responding to responsible disclosures from industry researchers.
The post Netop Vision Pro – Distance Learning Software is 20/20 in Hindsight appeared first on McAfee Blogs.
In this report the McAfee Advanced Threat Research (ATR) Strategic Intelligence team details an espionage campaign, targeting telecommunication companies, dubbed Operation Diànxùn.
In this attack, we discovered malware using similar tactics, techniques and procedures (TTPs) to those observed in earlier campaigns publicly attributed to the threat actors RedDelta and Mustang Panda. While the initial vector for the infection is not entirely clear, we believe with a medium level of confidence that victims were lured to a domain under control of the threat actor, from which they were infected with malware which the threat actor leveraged to perform additional discovery and data collection. We believe with a medium level of confidence that the attackers used a phishing website masquerading as the Huawei company career page to target people working in the telecommunications industry.
We discovered malware that masqueraded as Flash applications, often connecting to the domain “hxxp://update.careerhuawei.net” that was under control of the threat actor. The malicious domain was crafted to look like the legitimate career site for Huawei, which has the domain: hxxp://career.huawei.com. In December, we also observed a new domain name used in this campaign: hxxp://update.huaweiyuncdn.com.
Moreover, the sample masquerading as the Flash application used the malicious domain name “flach.cn” which was made to look like the official web page for China to download the Flash application, flash.cn. One of the main differences from past attacks is the lack of use of the PlugX backdoor. However, we did identify the use of a Cobalt Strike backdoor.
By using McAfee’s telemetry, possible targets based in Southeast Asia, Europe, and the US were discovered in the telecommunication sector. We also identified a strong interest in German, Vietnamese and India telecommunication companies. Combined with the use of the fake Huawei site, we believe with a high level of confidence that this campaign was targeting the telecommunication sector. We believe with a moderate level of confidence that the motivation behind this specific campaign has to do with the ban of Chinese technology in the global 5G roll-out.
Activity linked to the Chinese group RedDelta, by peers in our industry, has been spotted in the wild since early May 2020. Previous attacks have been described targeting the Vatican and religious organizations.
In September 2020, the group continued its activity using decoy documents related to Catholicism, Tibet-Ladakh relations and the United Nations General Assembly Security Council, as well as other network intrusion activities targeting the Myanmar government and two Hong Kong universities. These attacks mainly used the PlugX backdoor using DLL side loading with legitimate software, such as Word or Acrobat, to compromise targets.
While external reports have given a new name to the group which attacked the religious institutions, we believe with a moderate level of confidence, based on the similarity of TTPs, that both attacks can be attributed to one known threat actor: Mustang Panda.
We believe the best way to protect yourself from this type of attack is to adopt a multi-layer approach including MVISION Insights, McAfee Web Gateway, MVISION UCE and MVISION EDR.
MVISION Insights can play a key role in risk mitigation by proactively collecting intelligence on the threat and your exposure.
McAfee Web Gateway and MVISION UCE provide multi-layer web vector protection with URL Reputation check, SSL decryption, and malware emulation capabilities for analyzing dangerous active Web content such as Flash and DotNet. MVISION UCE also includes the capabilities of Remote Browser Isolation, the only solution that can provide 100% protection during web browsing.
McAfee Endpoint Security running on the target endpoint protects against Operation Dianxun with an array of prevention and detection techniques. ENS Threat Prevention and ATP provides both signature and behavioral analysis capability which proactively detects the threat. ENS also leverages Global Threat Intelligence which is updated with known IoCs. For DAT based detections, the family will be reported as Trojan-Cobalt, Trojan-FSYW, Trojan-FSYX, Trojan-FSZC and CobaltStr-FDWE.
As the last phase of the attack involves creating a backdoor for remote control of the victim via a Command and Control Server and Cobalt Strike Beacon, the blocking features that can be activated on a Next Generation Intrusion Prevention System solution such as McAfee NSP are important, NSP includes a Callback Detection engine and is able to detect and block anomalies in communication signals with C2 Servers.
MVISION EDR can proactively identify persistence and defense evasion techniques. You can also use MVISION EDR to search the indicators of compromise in Real-Time or Historically (up to 90 days) across enterprise systems.
Learn more about Operation Diànxùn, including Yara & Mitre ATT&CK techniques, by reading our technical analysis and Defender blog.
We assess with a high level of confidence that:
We assess with a moderate level of confidence that:
PLEASE NOTE: We have no evidence that the technology company Huawei was knowingly involved in this Campaign.
McAfee Advanced Threat Research (ATR) is actively monitoring this threat and will update as its visibility into the threat increases.
The post Operation Diànxùn: Cyberespionage Campaign Targeting Telecommunication Companies appeared first on McAfee Blogs.
In a recent report the McAfee Advanced Threat Research (ATR) Strategic Intelligence team disclosed an espionage campaign, targeting telecommunication companies, named Operation Diànxùn.
The tactics, techniques and procedures (TTPs) used in the attack are like those observed in earlier campaigns publicly attributed to the threat actors RedDelta and Mustang Panda. Most probably this threat is targeting people working in the telecommunications industry and has been used for espionage purposes to access sensitive data and to spy on companies related to 5G technology.
While the initial vector for the infection is not entirely clear, the McAfee ATR team believes with a medium level of confidence that victims were lured to a domain under control of the threat actor, from which they were infected with malware which the threat actor leveraged to perform additional discovery and data collection. It is our belief that the attackers used a phishing website masquerading as the Huawei company career page.
So, how can I defend my organization as effectively as possible from an attack of this type, which involves different techniques and tactics and potential impact? To answer this question, we believe it is necessary to have a multi-layer approach and analyze the various steps, trying to understand the best way to deal with them one by one with an integrated security architecture. Below is a summary of how McAfee’s Security Architecture helps you to protect against the tactics and techniques used in Operation Dianxun.
The goal is to shift-left and block or identify a threat as soon as possible within the Kill Chain to limit any further damage. Shifting-left starts with MVISION Insights, which proactively collects intelligence on the threat and provides details on the indicators of compromise and the MITRE techniques used in the attack. MVISION Insights combines McAfee’s Threat Intelligence research with telemetry from your endpoint controls to reduce your attack surface against emerging threats. MVISION Insights tracks over 800+ Advanced Persistent Threat and Cyber Crime campaigns as researched by McAfee’s ATR team, including Operation Dianxun, sharing a quick summary of the threat, providing external resources, and a list of known indicators such as files, URLs, or IP addresses.
As a threat intelligence analyst or responder, you can drill down into the MVISION Insights interface to gather more specific information on the Operation Dianxun campaign, verify the associated severity, check for geographical prevalence and links to other sources of information. Moreover, MVISION Insights provides useful information like the McAfee products coverage with details of minimum AMCore version; this kind of information is handy to verify actual defensive capabilities within the enterprise and could raise the risk severity in case of weak coverage.
Additional information is available to further investigate on IoCs and MITRE Techniques associated to the campaign. IoCs can be also exported in STIX2 format to be ingested in other tools for automating responses or updating defenses.
The first step ahead of identification is to ensure our architecture can stop or identify the threat in the initial access vector. In this case, the initial delivery vector is a phishing attack so the web channel is therefore fundamental in the initial phase of the infection. McAfee Web Gateway and MVISION UCE provide multi-layer web vector protection with URL Reputation check, SSL decryption, and malware emulation capabilities for analyzing dangerous active Web content.
MVISION UCE also includes the capabilities of Remote Browser Isolation (RBI), the only solution that can provide 100% protection during web browsing. Remote Browser Isolation is indeed an innovative new technology that contains web browsing activity inside an isolated cloud environment in order to protect users from any malware or malicious code that may be hidden on a website. RBI technology provides the most powerful form of web threat protection available, eliminating the opportunity for malicious code to even touch the end user’s device.
The green square around the page means that the web content is isolated by RBI and provided safely through a rendered dynamic visual stream which delivers full browsing experience without risk of infection.
The second phase of exploitation and persistence results from execution on the victim endpoint of Flash-based artifacts malware and, later, DotNet payload. McAfee Endpoint Security running on the target endpoint protects against Operation Dianxun with an array of prevention and detection techniques. ENS Threat Prevention and ATP provides both signature and behavioral analysis capability which proactively detects the threat. ENS also leverages Global Threat Intelligence which is updated with known IoCs. For DAT based detections, the family will be reported as Trojan-Cobalt, Trojan-FSYW, Trojan-FSYX, Trojan-FSZC and CobaltStr-FDWE.
While the execution of the initial fake Flash installer acts mainly like a downloader, the DotNet payload contains several functions and acts as a utility to further compromise the machine. This is a tool to manage and download backdoors to the machine and configure persistence. Thus, the McAfee Endpoint Security Adaptive Threat Protection machine-learning engine triggers detection and blocks execution on its behavior-based analysis.
The last phase of the attack involves creating a backdoor for remote control of the victim via a Command and Control Server and Cobalt Strike Beacon. In this case, in addition to the detection capabilities present at the McAfee Endpoint Security level, detections and blocking features that can be activated on a Next Generation Intrusion Prevention System solution such as McAfee NSP are important. NSP includes a Callback Detection engine and is able to detect and block anomalies in communication signals with C2 Servers.
We demonstrated above how a well defended architecture can thwart and counteract such an attack in each single phase. McAfee Web Gateway and MVISON Unified Cloud Edge can stop the initial entry vector, McAfee Endpoint Protection Platform can block the dropper execution or disrupt the following malicious activities but, only by using MVISION EDR, can you get extensive visibility on the full kill chain.
On MVISION EDR we have the threat detection on the monitoring dashboard for the two different stages and processes of the attack.
Once alerted, the security analyst can dig into the Process Activity and understand behavior and indicators relative to what happened like:
The initial downloader payload flashplayer_install_cn.exe is executed directly by the user and spawned by svchost.exe.
At first it connects back to hxxp://update.flach.cn registering to the c2 and creates a new executable file, flash.exe, in the Windows/temp folder.
Then the sample checks the time and the geolocalization of the infected machine via a request to http://worldclockapi.com.
Next, it connects back to the fake Huawei website “hxxp:\\update.careerhuawei.net” used for the initial phishing attack.
Finally, to further completion, you can also use MVISION EDR to search the indicators of compromise in Real-Time or Historically (up to 90 days) across the enterprise systems.
Looking for other systems with evidence of connection to the fake Huawei website:
HostInfo hostname, ip_address and NetworkFlow src_ip, proto, time, process, md5, user where NetworkFlow dst_ip equals “8.210.186.138”
Looking for indicators of the initial downloader payload linked to this campaign.
HostInfo and Files name, full_name, create_user_name, sha1, md5, sha256 where Files sha256 equals “422e3b16e431daa07bae951eed08429a0c4ccf8e37746c733be512f1a5a160a3” or Files sha256 equals “8489ee84e810b5ed337f8496330e69d6840e7c8e228b245f6e28ac6905c19f4a ” or Files sha256 equals “c0331d4dee56ef0a8bb8e3d31bdfd3381bafc6ee80b85b338cee4001f7fb3d8c” or Files sha256 equals “89a1f947b96b39bfd1fffd8d0d670dddd2c4d96f9fdae96f435f2363a483c0e1” or Files sha256 equals “b3fd750484fca838813e814db7d6491fea36abe889787fb7cf3fb29d9d9f5429” or Files sha256 equals “9ccb4ed133be5c9c554027347ad8b722f0b4c3f14bfd947edfe75a015bf085e5” or Files sha256 equals “4e7fc846be8932a9df07f6c5c9cbbd1721620a85c6363f51fa52d8feac68ff47” or Files sha256 equals “0f2e16690fb2ef2b5b4c58b343314fc32603364a312a6b230ab7b4b963160382” or Files sha256 equals “db36ad77875bbf622d96ae8086f44924c37034dd95e9eb6d6369cc6accd2a40d” or Files sha256 equals “8bd55ecb27b94b10cb9b36ab40c7ea954cf602761202546f9b9e163de1dde8eb” or Files sha256 equals “7de56f65ee98a8cd305faefcac66d918565f596405020178aee47a3bd9abd63c” or Files sha256 equals “9d4b4c39106f8e2fd036e798fc67bbd7b98284121724c0f845bca0a6d2ae3999” or Files sha256 equals “ac88a65345b247ea3d0cfb4d2fb1e97afd88460463a4fc5ac25d3569aea42597” or Files sha256 equals “37643f752302a8a3d6bb6cc31f67b8107e6bbbb0e1a725b7cebed2b79812941f” or Files sha256 equals “d0dd9c624bb2b33de96c29b0ccb5aa5b43ce83a54e2842f1643247811487f8d9” or Files sha256 equals “260ebbf392498d00d767a5c5ba695e1a124057c1c01fff2ae76db7853fe4255b” or Files sha256 equals “e784e95fb5b0188f0c7c82add9a3c89c5bc379eaf356a4d3876d9493a986e343” or Files sha256 equals “a95909413a9a72f69d3c102448d37a17659e46630999b25e7f213ec761db9e81” or Files sha256 equals “b7f36159aec7f3512e00bfa8aa189cbb97f9cc4752a635bc272c7a5ac1710e0b” or Files sha256 equals “4332f0740b3b6c7f9b438ef3caa995a40ce53b3348033b381b4ff11b4cae23bd”
Look back historically for domain name resolution and network connection to the involved indicators.
To defeat targeted threat campaigns like Operation Dianxun, defenders must build an adaptive and integrated security architecture which will make it harder for threat actors to succeed and increase resilience in the business. This blog highlights how to use McAfee’s security solutions to prevent, detect and respond to Operation Dianxun and attackers using similar techniques.
McAfee ATR is actively monitoring this campaign and will continue to update McAfee Insights and its social networking channels with new and current information. Want to stay ahead of the adversaries? Check out McAfee Insights for more information.
The post McAfee Defender’s Blog: Operation Dianxun appeared first on McAfee Blogs.
For the March 2021 Patch Tuesday, Microsoft released a set of seven DNS vulnerabilities. Five of the vulnerabilities are remote code execution (RCE) with critical CVSS (Common Vulnerability Scoring Standard) scores of 9.8, while the remaining two are denial of service (DoS). Microsoft shared detection guidance and proofs of concept with MAPP members for two of the RCE vulnerabilities, CVE-2021-26877 and CVE-2021-26897, which we have confirmed to be within the DNS Dynamic Zone Update activity. Microsoft subsequently confirmed that all seven of the DNS vulnerabilities are within the Dynamic Zone Update activity.
We confirmed from our analysis of CVE-2021-26877 and CVE-2021-26897, in addition to further clarification from Microsoft, that none of the five DNS RCE vulnerabilities are wormable.
RCE vulnerabilities
CVE-2021-26877, CVE-2021-26897 (exploitation more likely)
CVE-2021-26893, CVE-2021-26894, CVE-2021-26895 (exploitation less likely)
DoS vulnerabilities
CVE-2021-26896, CVE-2021-27063 (exploitation less likely)
A critical CVSS score of 9.8 means that an attacker can remotely compromise a DNS server with no authentication or user interaction required. Successful exploitation of these vulnerabilities would lead to RCE on a Primary Authoritative DNS server. While CVSS is a great tool for technical scoring, it needs to be taken in context with your DNS deployment environment to understand your risk which we discuss below.
We highly recommend you urgently patch your Windows DNS servers if you are using Dynamic Updates. If you cannot patch, we recommend you prioritize evaluating your exposure. In addition, we have developed signatures for CVE-2021-26877 and CVE-2021-26897 which are rated as “exploitation more likely” by Microsoft.
Per the NIST “Secure Domain Name System (DNS) Deployment Guide”, DNS threats can be divided into Platform and Transaction Threats. The platform threats can be classed as either DNS Host Platform or DNS Software Threats. Per Table 1 below, Dynamic Update is one of the four DNS Transaction types. The seven DNS vulnerabilities are within the Dynamic Update DNS transaction feature of Windows DNS Software.
Table 1: DNS Transaction Threats and Security Objectives
The DNS Dynamic Zone Update feature allows a client to update its Resource Records (RRs) on a Primary DNS Authoritative Server, such as when it changes its IP address; these clients are typically Certificate Authority (CA) and DHCP servers. The Dynamic Zone Update feature can be deployed on a standalone DNS server or an Active Directory (AD) integrated DNS server. Best practice is to deploy DNS integrated with (AD) so it can avail itself of Microsoft security such as Kerberos and GSS-TSIG.
When creating a Zone on a DNS server there is an option to enable or disable DNS Dynamic Zone Updates. When DNS is deployed as a standalone server, the Dynamic Zone Update feature is disabled by default but can be enabled in secure/nonsecure mode. When DNS is deployed as AD integrated, the Dynamic Zone Update feature is enabled in secure mode by default.
Secure Dynamic Zone Update verifies that all RR updates are digitally signed using GSS-TSIG from a domain-joined machine. In addition, more granular controls can be applied on what principal can perform Dynamic Zone Updates.
Insecure Dynamic Zone Update allows any machine to update RRs without any authentication (not recommended).
From a Threat Model perspective, we must consider Threat Actor motives, capabilities, and access/opportunity, so you can understand the risk relative to your environment. We are not aware of any exploitation in the wild of these vulnerabilities so we must focus on the access capabilities, i.e., close the door on the threat actor opportunity. Table 2 summarizes DNS Dynamic Update deployment models relative to the opportunity these RCE vulnerabilities present.
Table 2: Threat Actor access relative to deployment models and system impact
The highest risk deployment would be a DNS server in Dynamic Update insecure mode exposed to the internet; this is not best security practice and based on our experience, we do not know of a use case for such deployment.
Deploying AD integrated DNS Dynamic Update in secure mode (default) mitigates the risk of an unauthenticated attacker but still has a high risk of a compromised domain computer or trusted insider being able to achieve RCE.
All the vulnerabilities are related to the processing of Dynamic Update packets in dns.exe. The goal of our vulnerability analysis, as always for critical industry vulnerabilities, is to ensure we can generate accurate signatures to protect our customers.
Figure 1: Wireshark view of exploit packet classifying the DNS packet as malformed
Figure 2: WinDbg output of crash while attached to dns.exe
FreshRSS 
File_PlaceStringInFileBuffer() function copies data from TXT_data allocated from CopyWireRead() function previously. However, the UpdateRR->TXT length value from Wireshark is not validated and used to copy from *UpdateRR->Data length. Because UpdateRR->TXT length is not validated relative to UpdateRR->Data length it results in a OOB read from heap memory.
Figure 3: Packet containing many consecutive Signature RR dynamic updates. Pay special attention to the length field of the reassembled flow.
Exploiting these vulnerabilities remotely requires both read and write primitives in addition to bypassing Control Flow Guard (CFG) for execution. The DNS protocol has significant remote unauthenticated attack surface to facilitate generating such primitives which has been researched as part of CVE-2020-1350 (SigRed). In addition, per the RR_DispatchFuncForType() function, there are read and write functions as part of its dispatch table.
Figure 4: Path of DNS RR update packet
Figure 5: Dispatch functions for reading and writing
Patching is always the first and most effective course of action. If it’s not possible to patch, the best mitigation is to audit your DNS deployment configuration to limit Dynamic Zone Updates to trusted servers only. For those McAfee customers who are unable to deploy the Windows patch, the following Network Security Platform (NSP) signatures will provide a virtual patch against attempted exploitation of both vulnerabilities, CVE-2021-26877 and CVE-2021-26897.
NSP Attack ID: 0x4030e700 – DNS: Windows DNS Server Remote Code Execution Vulnerability (CVE-2021-26877)
NSP Attack ID: 0x4030e800 – DNS: Windows DNS Server Remote Code Execution Vulnerability (CVE-2021-26897)
In addition, NIST “Secure Domain Name System (DNS) Deployment Guide” provides best practices for securing DNS deployment such as:
The post Seven Windows Wonders – Critical Vulnerabilities in DNS Dynamic Updates appeared first on McAfee Blogs.
The generosity and kindness displayed by team members across McAfee is one major factor that makes up the incredible culture of the company. At McAfee, we empower our team members to initiate meaningful ways to give back to the community. It came to no surprise when a large group of team members came together in order to run a donation drive to benefit the Make-A-Wish Foundation.
The Make-A-Wish Foundation is a nonprofit corporation that helps grant wishes to thousands of children fighting life-threatening medical conditions. One way to support the foundation is by donating airline miles. Nationally, Make-A-Wish needs more than 2.8 billion miles, or 50,000 round-trip tickets, to cover every child’s travel wish each year. Every mile donated will help kids and their families travel to destinations around the world, once it is safe to resume travel. It is just one of the ways that individuals can help create a life-changing wish experience.
Some of our team members organized an air miles donation drive and encouraged others to donate their miles to the cause. The impact was astronomical, with team members raising over 585,000 miles to benefit the Make–a–Wish Foundation in the Bay Area.
We reached out to three airline mile contributors at McAfee and discussed what inspired them to contribute to this extraordinary initiative.
Derek, Product Manager, Hawaii
I was happy to see the McAfee family come together and support a terrific cause by donating airline miles to the Make-A-Wish Foundation. Giving is a key element in my faith and a core value. I knew that I could either cash in the points and do something with my family, or I could put the miles towards an even greater purpose and help a child who is truly in need of experiencing something special. The choice was an easy one to make.
I believe that helping others is one of our top callings. That is why I choose to give and do so generously with joy. I know that I’m not alone here at McAfee. There is a great culture of generosity that I’ve witnessed across the organization and I’m happy to simply be a part of that and do what I can to help others.
Laura, Senior Manager Business Operations, Santa Clara, California Years ago, my brother was a starving college student who volunteered for a local charity and drove cancer patients to their medical appointments. When I asked him about his volunteer work, he said that he didn’t have a lot of money, but he had time. Volunteering allowed him to make a difference in someone’s life and give back. It was a life–changing moment for me because it expanded how I think about giving to include time, donations and acts of kindness.
I chose to participate in the air miles donation drive because I love that this program provides time for critically ill children to spend with their loved ones while creating memorable and happy experiences.
I am incredibly grateful to our McAfee leaders who create opportunities for us to give back. Giving back is at the core of McAfee’s DNA and having closely connected teams makes it easy for team members to answer a call to action.
Pramod, Principal Engineer, Portland, Oregon
Giving is all about making small differences whenever and wherever you can, in any form. We can make a huge difference in the lives of others, especially when we are in a position where we can help those who need us the most.
When team members from the enterprise organization set up a drive for the Make-A-Wish Foundation, it connected with me on a personal level. As I went through the stories of children whose wishes were granted through the program, I was moved to learn about how a little effort can create the best moments in someone’s life.
Meaningful communication from our HR team members and leadership promoting efforts to volunteer and give back to the community are motivating. I like that McAfee has a dedicated site that team members can access for giving and that there are opportunities in which McAfee matches team member donations. Collectively, we can make a big difference to the world around us. Truly, together is power.
At McAfee, we encourage and support the efforts of our team members to make a difference in their communities. If you’re interested in joining the McAfee team, we’d love to hear from you.
Search Career Opportunities with McAfee
Interested in joining our team? We’re hiring! Apply now.
Stay Connected
For more stories like this, follow @LifeAtMcAfee on Instagram and @McAfee on Twitter to see what working at McAfee is all about.
The post How a Group of McAfee Team Members Helped Change the Lives of Critically Ill Children appeared first on McAfee Blogs.
My McAfee Chronicles is a series featuring McAfee team members who have interesting and inspiring life stories to share. Meet Shiva, a Software Development Engineer in Bangalore, India.
When a traumatic road accident changed the course of Shiva’s life, he had two options – give up on life or give life his best shot. For Shiva, there was only one obvious choice. Through his unrelenting willpower and sheer determination, he was able to overcome all odds.
Shiva shares his deeply inspirational story below:
My journey at McAfee started in 2011 when I joined the company. In 2013, my life was turned upside down. I was on a road trip with a few friends when we got in a car accident. Although I was fortunate enough to survive, unlike two of my friends, I suffered from a severe nerve injury that left me paralyzed from the neck down.
The next few months were some of the roughest of my life. Due to the extent of my injuries, I spent several months recuperating in the hospital. Soon, I hit my limit for medical insurance coverage. No one is ever prepared to face such a financial situation and I was no different. However, I was extremely fortunate that McAfee came forward and supported me in every possible way, both financially and emotionally. With McAfee’s support, I was able to receive the best treatment for my needs.
I spent close to 10 months in the hospital and doing rehab, slowly picking up the pieces of my life again. Even simple things like sitting or talking to someone took me a great deal of effort. However, giving up was never an option for me. My doctors encouraged me to engage mentally, and that’s when I slowly started to contribute at work again.
Before my accident, I led two projects for my team. Even though my mobility was restricted, I still have the ability to think. So, my team came forward and encouraged me to work again. I started at a slow pace, mostly talking on the phone and sharing my thoughts with my team. My team served as my hands and legs, coding and working on my unfinished projects. My leaders and team members turned out to be my biggest strength. They would visit me often to cheer me up and we would celebrate special occasions together. I was overwhelmed by their love and support.
Finally, it was time to get back to the office. When I started walking a little, I slowly got back to work in a phased manner. McAfee gave me the flexibility that I needed to put together the pieces of my life. Although it was wonderful to be back, returning didn’t come without its challenges. I could not drive to work anymore. For some time, my teammates helped me get to the office. On other occasions, I would hire a taxi. On the days when it rained, it was challenging to find a cab, given Bangalore’s traffic.
Around the same time, McAbility was formed in India. I became a part of it and brought my commute issue to McAfee’s knowledge. I’m glad to say that McAfee did not hesitate to arrange a special cab exclusively for me. McAfee welcomed and acted on every suggestion that I shared regarding improving mobility issues in the office.
With the support of my family, team members and McAfee, life slowly started to get back to normal. I even got a chance to visit my colleagues in the Cork office, which was a life changing moment for me. The support that I received from everyone around me was a crucial part of my recovery. Even now when I’m in the office, people stop by and ask me how I am doing and it is heartwarming.
“Any emotion, if it is sincere, is involuntary”, by Mark Twain. If you want to be a good person or be kind to someone, it will come to you naturally. You wouldn’t have to try too hard.
For more stories like Shiva’s or to learn more about our company culture, follow @LifeatMcAfee on Instagram and @McAfee on Twitter.
Interested in joining McAfee? We’re hiring! Apply now.
The post Shiva’s Tragic Accident Turns into a Story of Resilience appeared first on McAfee Blogs.
By: Smriti, People Partner
McAfee continues to recognize and celebrate hardworking mothers across our global workforce. We continue to advance in our workplace culture by offering policies and programs to better serve working parents.
Meet Smriti as she shares her incredible story as a new mother and how McAfee helped her to transition comfortably into a new role as a working parent.
My journey at McAfee began in 2017 as a People Partner. My role includes developing policies and processes for People Success.
My husband and I were delighted to welcome our first-born. In 2019, we welcomed our daughter into our family. While becoming a new parent is both rewarding and fulfilling, it can also be an overwhelming experience. The job of a parent is never-ending. There is no 9 – 5 schedule and you can’t check out. You’re always on parent duty 24 hours a day, 7 days a week.
McAfee’s family-friendly policies and benefits helped our new family bond together. I spent quality time with my daughter during my maternity leave. From receiving baby gifts in the mail from McAfee to getting the insurance coverage and mental health support that I needed, McAfee’s benefits for working parents were a blessing for us.
Parenthood is never without its obstacles, and most times, unforeseen ones. When my family could not make it home due to travel restrictions because of COVID-19, I got the support I needed to extend my leave. I also opted for the Gradual Return to Work Program designed for new moms. This ensured that I would not be overwhelmed when reentering the workforce and that my priorities were well understood.
I received a warm welcome from everyone, including my team and my manager. I consider myself fortunate to work for a company that understands the value of a new family. Working moms often struggle with work and family. Still, with a little support, they can indeed thrive in their workplaces and have a fruitful career.
My Life’s Manta is to always look at the bigger picture in life and be thankful for what you have, rather than think about the downsides. Personally, this helps me to be happy and content.
All over the world, McAfee’s benefits continue to evolve to reflect the needs of working parents. From extended bonding leave to expanded opportunities that help parents transition with our Return to Workplace program, we work tirelessly to create a range of programs unique to each country. We continue to support those who have paused their careers to care for their families as well as new working parents.
Learn more about the ways McAfee is serving working parents and building an inclusive workplace by following Life at McAfee on Instagram and @McAfee on Twitter.
Interested in joining forces with us? Explore our job opportunities. Subscribe to job alerts.
The post How McAfee’s Inclusive Maternity Benefits Helped Me Thrive as a New Mom appeared first on McAfee Blogs.
John Lambert, a distinguished researcher specializing in threat intelligence at Microsoft, once said these words that changed perspectives: “Defenders think in lists. Attackers think in graphs.” This is true and, while it remains that way, attackers will win most of the time. However, the true power of graphs does not only reside in constructing them, but also in how we build them and what we do with them. For that, we need to reflect upon the nature of the data and how we can use graphs to make sense of it. I presented on this premise at the MITRE ATT&CKcon Power Hour held in January 2021.
At McAfee Advanced Threat Research (ATR), all threat intelligence relating to current campaigns, potential threats, and past and present attacks, is collated and normalized into a single truth, namely a highly redundant, scalable relational database instance, and disseminated into different categories, including but not limited to MITRE ATT&CK techniques involved, tools used, threat actor responsible, and countries and sectors targeted. This information is a subset of the data available in McAfee MVISION Insights. Much can be learned from looking at historical attack data, but how can we piece all this information together to identify new relationships between threats and attacks? We have been collecting and processing data for many years but identifying patterns quickly and making sense of the complete dataset as a whole has proven to be a real challenge.
In our recent efforts, we have embraced the analysis of threat intelligence using graphical representations. One key takeaway is that it is not just about mapping out intelligence about campaigns and threats into graphs; the strength lies in studying our datasets and applying graph algorithms to answer questions about the data.
In this paper, we provide an extensive description of the dataset derived from the threat intelligence we collect. We establish the methodology applied to validate our dataset and build our graphical representations. We then showcase the results obtained from our research journey as defenders thinking in graphs instead of lists.
The first section explains the kind of data we have at our disposal. The second section describes the goal of our research and the kind of questions we want to answer. Sections 3 and 4 establish the methodology used to process our dataset and to validate that we can actually do something useful with it by using graphs. The fifth section describes the process of building graphs, and Section 6 shows how we use these graphs to answer the questions laid out in Section 2. Section 7 introduces an additional research element to add more granularity to our experiment, and Section 8 shares the limitations of our research and potential ways to compensate for them. Sections 9 and 10 conclude this research with some reflections and proposed future work.
Our dataset consists of threat intelligence, either collected by or shared with our team, is piped into our internal MISP instance and published to relevant stakeholders. This data concerns information about campaigns, crimeware or nation-state attacks that are currently going on in the world, from potential or reoccurring threat (groups). The data is split into multiple categories used to establish everything we know about the four basic questions of what, who, where, and how. For example, certain attacks on countries in the Middle East have been conducted by the group MuddyWater and have targeted multiple companies from the oil and gas and telecom industries, leveraging spear phishing campaigns. The dataset used for this research is a collection of the answers to these four basic questions about each event.
The quantity of data we have makes it almost impossible to make sense in one pass. Information is scattered across hundreds of events, in a database that does not necessarily enable us to connect each piece of information we have in relevant patterns. The goal of this research is to create a methodology for us to quickly connect and visualize information, identify patterns in our data that could reveal trends in, for example, actor behaviour or MITRE technique usage. In this paper, we specifically focus on actor trends and MITRE technique usage.
By providing such tooling, we can answer questions about frequency of actors or techniques, popularity of techniques across actors, and patterns of behaviour in technique usage among actors. These questions are laid out as such:
These questions are not exhaustive of everything that can be achieved using this methodology, but they reveal an example of what is possible.
As we are proposing a way to build graphs to make sense of the data we have, we first need to validate our dataset to make sure graphs will deliver something useful. For that, we need to look at expected density and connectivity of the graph. Should our dataset be too dense and overly connected, building graphs will not result in something that can be made sense of.
After establishing that our dataset is graphable, we can focus on how exactly we will graph it. We need to establish what our nodes are and what defines our edges. In this case, we propose two representations: an event-centric view and actor-centric view, respectively taking events and actors as points of reference.
Once we have built our graphs, we investigate different techniques and algorithms to answer the questions laid out in the previous section. This experiment provides us insights into our data, but also into what we are missing from our data that could give us even more information.
The tooling used for this research is an internal tool referred to as Graph Playground that provides users with the possibility to build client-side undirected graphical visualizations in their browser, based on CSV or JSON files. This software also offers a toolbox with analysis techniques and algorithms to be used on the graphs.
Before building proper graphical representations, we need to assess whether the dataset is a good fit. There are a few metrics that can indicate that the dataset is not necessarily fit for graphs, one of which being the average number of connections (edges) per node:
This average gives us an approximate indication of how many edges per node we can expect. Another useful metric is graph density, defined as the number of edges divided by the total number of possible edges for an undirected simple graph. This is normally calculated using the following formula:
It is a simple equation, but it can already give great insights as to what the graph is going to look like. A graph with high density might be a super connected graph where every node relates to one another in some way. It can be great for visualisation but will not provide us with anything useful when it comes to identifying patterns or differentiating between the different components of the graph.
Based on the data at hand, one intuitive way to build graphs is using a threat event as a central node and connected nodes that represent MITRE techniques, threat actors, tools, countries, and sectors to that event node.
Figure 1: Graph representation of the data
Figure 1 depicts the initial graphical representation using each event and associated metadata registered in MISP. Relationships between event nodes and other nodes are defined as follows: techniques and tools are used in one event that is attributed to a specific actor and involves a threat or attack on certain countries and sectors.
Based on the representation and our dataset, the number of nodes obtained is |N| = 1,359 and the total number of edges is |E| = 12,327. In our case, because only event nodes are connected to other nodes, if we want to check for the average number of edges per node, we need to look specifically at event nodes. In the obtained graph g, this average is equal to:
To calculate the density, we also need to account for the fact that only event nodes have connections. The density of the obtained graph g is then equal to:
Density always results in a number between 0 and 1. With an average of 18 edges per event node and a graph density of 0.053, we can expect the resulting graph to be relatively sparse.
Figure 2: Full representation of 705 MISP events
The full graph obtained with this representation in Figure 2, against our predictions, looks much denser than expected. It has an obvious central cluster that is busy with nodes that are highly interconnected, consisting mostly of event and technique nodes. In Figure 3, we discard MITRE technique nodes, leaving event, country, sector, and tool nodes, to demonstrate where the low-density calculation comes from.
Figure 3: Representation without MITRE technique nodes
Removing MITRE technique nodes results in a much less dense graph. This may be an indication that some event and technique nodes are highly interconnected, meaning there may be a lot of overlap between events and techniques used.
Figure 4: Representation with only event and MITRE technique nodes
Figure 4 proves this statement by showing us a large cluster of interconnected event and technique nodes. There is a set of events that all appear to be using the same technique. It would be interesting to isolate this cluster and take note of exactly which techniques these are, but this research takes us down another road.
Based on the data we have, which mostly consists of events relating to crimeware, we choose to disregard country and sector information in our graphical analyses. This is because these campaigns are most often sector and country-agnostic, based on historical observation. Therefore, we proceed without country and sector data. This allows us to perform some noise reduction, keeping events as points of reference.
We can also take this a step further and collapse event nodes to switch the focus to actor nodes with regard to tools and MITRE techniques used. This results in two different representations derived from the original graph.
Removing country and sector nodes, we are left with event nodes connected to actor, technique, and tool nodes. Figure 5 illustrates this representation.
Figure 5: Representation without country and sector nodes
This resulting representation is an event-centric view, and it can help us answer specific questions about frequency of actors involved, techniques or tools used during recorded attacks and campaigns.
Figure 6: Event-centric view
The graph in Figure 6 is very similar to the original one in Figure 2, but the noise that is not of real interest at this stage has been removed, so that we can really focus on events regarding actors, techniques, and tools.
Another possible representation, because the data we have about countries and sectors is very sparse, is to center the graph around actor nodes, connected to techniques and tools.
Figure 7: Collapsed presentation of actors, techniques, and tools
Figure 7 establishes the relationship between the three remaining nodes: actor, technique, and tools. The resulting graph is displayed in Figure 8.
Figure 8: Actor-centric view
These two ways to build graphs based on our data provide an event-centric view and an actor-centric view and can be used to answer different questions about the gathered intelligence.
Based on the two generated views for our data, we demonstrate how certain algorithms and graph-related techniques can be used to answer the questions posed in Section 2. Each view provides insights on frequency, popularity, or pattern questions.
Which techniques are observed most often?
To answer questions about the frequency of techniques used, we need to take the event-centric view, because we are directly addressing how often we have observed techniques being used. Therefore, we take this view and look at the degree of nodes in the graph. Nodes with a high degree are nodes with more connections. A MITRE technique node with a very high degree is a node that is connected to a high number of events.
Figure 9: Degree analysis on the event-centric view with a focus on techniques
Figure 9 shows us the application of degree analysis on the event-centric view, revealing techniques like Spearphishing Attachment and Obfuscated Files or Information as the most often observed techniques.
Which actors are the most active?
The same degree analysis can be used on this view to identify which actors have most often been recorded.
Figure 10: Degree analysis on the event-centric view with a focus on actors
Based on the results displayed in Figure 10, Sofacy, Lazarus Group, and COVELLITE are the most recorded actors across our data.
Which techniques are the most common across actors?
To answer questions about popularity of techniques across actors, we need to look at the actor-centric view, because it will show us how techniques and actors relate to one another. While degree analysis would also work, we can make use of centrality algorithms that measure how much control a certain node has over a network, or in other terms: how popular a certain node is.
Figure 11: Centrality algorithm used on the actor-centric view
Running centrality algorithms on the graph shows us that Obfuscated Files or Information and User Execution are two of the most popular techniques observed across actors.
Can we identify groups of actors using the same techniques?
The keyword here is groups of actors, which insinuates that we are looking for clusters. To identify groups of actors who use the same techniques, we can attempt to use clustering algorithms to isolate actors who behave the same way. We need to apply these algorithms on the actor-centric view. However, we also see that our actor-centric view in Figure 8 has quite a dense bundle of nodes, and this could make the building of clusters more difficult.
Figure 12: Clustering algorithm used on the actor-centric view
Louvain Clustering is a community detection technique that builds clusters based on edge density; Figure 12 shows us the results of running this algorithm. We see that it was possible to build some clusters, with a clear distinction between the orange cluster and the bundle of nodes, but it is not possible to verify how accurate our clusters are, because of the density of the subgraph where all the nodes seem to be interconnected.
We can draw two conclusions from this:
This takes us to the last important question:
Are actors using techniques in the same way?
With the information currently at our disposal, we cannot really assess whether a technique was used in the same way. It would be ideal to specify how an actor used a certain technique and encode that into our graphs. In the next section, we introduce an additional element to hopefully provide more granularity so we can better differentiate actors.
To provide more granularity and hopefully answer the question about actors using techniques in the same way, we embed killchain step information into our graphs. A certain attack can be used for multiple killchain steps. We believe that adding killchain step information to specify where an attack is used can help us better differentiate between actors.
Figure 13: Representation that introduces a killchain step node
This is a slight modification that occurs on our actor-centric view. The resulting graph should provide us with more granularity with regards to how a technique, that is present at multiple steps, was really used.
Figure 14: Actor-centric view with killchain information
The resulting graph displayed in Figure 14 is, for lack of a better word, disappointing. That is because killchain step information has not provided us with more granularity, which in turn is because of our dataset. Unfortunately, MISP does not let users specify when a technique is used in one specific step of the killchain, if that technique can occur in multiple steps. When recording an observed MITRE technique that can occur in multiple steps, all steps will be recorded with that technique.
MISP provides granularity in terms of MITRE sub-techniques, but there is no built-in differentiation on the killchain steps. It is not yet possible to specify exactly at which step a technique present in multiple steps is used. This removes a certain level of granularity that could be useful in the actor-centric view to differentiate even more between actors. If such differentiation existed, the actor-centric view could be collapsed into:
Additionally, based on the data at hand, it is clear that actors tend to use the same techniques overall. The question of whether using MITRE techniques to differentiate between actors is actually useful then comes to mind. Perhaps it can be used to discard some noticeably different actors, but not most?
Limitations of our research also lie in the tooling used. The Graph Playground is great for quick analyses, but more extensive manipulations and work would require a more malleable engine.
Lastly, our research focused on MISP events, threat actors, and MITRE techniques. While most questions about frequency, popularity, and pattern recognition can be answered the same way for tools, and even country and sector, the list of what is achievable with graphs is definitely not exhaustive.
Building graphs the right way helps us visualize our large dataset almost instantly, and it helps us make sense of the data we see. In our case, right means the way that is most relevant to our purpose. By having sensical and relevant representations, we can connect cyber threats, campaigns, and attacks to threat actors involved, MITRE techniques used, and more.
Graphical representations are not just about piping all our data into one visualization. We need to think of how we should build our graphs to get the most out of them, while attempting to maintain satisfactory performance when scaling those graphs. Graphs with thousands of nodes often take long to render, depending on the visualization engine. The Graph Playground generates graphs from a file on the client-side, in the browser. This makes the generation incredibly fast.
Certain aspects of our research require an event-centric view, while others may, for example, require an actor-centric view. We also need to assess whether building graphs is useful in the first place. Highly dense and connected data will result in graphs that cannot be used for anything particularly interesting for our analyses of threat intelligence.
Our research has proven fruitful in the sense that much can be gained from translating our dataset to adequate representations. However, we lack a certain granularity-level that could help us differentiate between certain aspects of our data even more.
To add to John Lambert’s quote, “Defenders think in lists. Attackers think in graphs. And Threat Intelligence analysts build proper graphs and exhaustively use them.”
As mentioned, we have encountered a granularity issue that is worth looking into for future research. It would be interesting to consider incorporating analysis results from EDR engines, to isolate where a specific MITRE ATT&CK technique was used. This would provide much deeper insights and potentially even more data we can include in our visualizations. Should we succeed and process this information into our graphs, we would be able to better differentiate between actors that otherwise seem to behave the same.
We can also shift our perspective and include country and sector information but, for that, we need to exclude all crimeware-related events that are sector or country-agnostic and include only campaigns that have specific targets. Only then will such representation be useful for further analysis.
Another point worth mentioning for future work would be to consider incorporating additional resources. The Intezer OST Map, which is open source, provides insights on tools used by threat actors for well-known campaigns. It would be interesting to merge the Intezer dataset with our own and experiment with our graph representations based on this new dataset.
The post McAfee ATR Thinks in Graphs appeared first on McAfee Blogs.
Babuk ransomware is a new ransomware threat discovered in 2021 that has impacted at least five big enterprises, with one already paying the criminals $85,000 after negotiations. As with other variants, this ransomware is deployed in the network of enterprises that the criminals carefully target and compromise. Using MVISION Insights, McAfee was able to plot the telemetry of targets, revealing that the group is currently targeting the transportation, healthcare, plastic, electronics, and agricultural sectors across multiple geographies.
Figure 1. Infection map (source: MVISION Insights)
McAfee’s EPP solution covers Babuk ransomware with an array of prevention and detection techniques.
ENS ATP provides behavioral content focusing on proactively detecting the threat while also delivering known IoCs for both online and offline detections. For DAT based detections, the family will be reported as Ransom-Babuk!<hash>. ENS ATP adds 2 additional layers of protection thanks to JTI rules that provide attack surface reduction for generic ransomware behaviors and RealProtect (static and dynamic) with ML models targeting ransomware threats.
Updates on indicators are pushed through GTI, and customers of Insights will find a threat-profile on this ransomware family that is updated when new and relevant information becomes available.
Initially, in our research the entry vector and the complete tactics, techniques and procedures (TTPs) used by the criminals behind Babuk remained unclear.
However, when its affiliate recruitment advertisement came online, and given the specific underground meeting place where Babuk posts, defenders can expect similar TTPs with Babuk as with other Ransomware-as-a-Service families.
In its recruitment posting Babuk specifically asks for individuals with pentest skills, so defenders should be on the lookout for traces and behaviors that correlate to open source penetration testing tools like winPEAS, Bloodhound and SharpHound, or hacking frameworks such as CobaltStrike, Metasploit, Empire or Covenant. Also be on the lookout for abnormal behavior of non-malicious tools that have a dual use, such as those that can be used for things like enumeration and execution, (e.g., ADfind, PSExec, PowerShell, etc.) We advise everyone to read our blogs on evidence indicators for a targeted ransomware attack (Part1, Part2).
Looking at other similar Ransomware-as-a-Service families we have seen that certain entry vectors are quite common amongst ransomware criminals:
When it comes to the actual ransomware binary, we strongly advise updating and upgrading your endpoint protection, as well as enabling options like tamper protection and rollback. Please read our blog on how to best configure ENS 10.7 to protect against ransomware for more details.
Learn more about the inner working of Babuk, underground forum activity, Yara Rules, Indicators of Compromise & Mitre ATT&CK techniques used by reading our detailed technical analysis.
Learn more about the inner working of Babuk, underground forum activity, Yara Rules, Indicators of Compromise & Mitre ATT&CK techniques used.
View Now
The post Babuk Ransomware appeared first on McAfee Blogs.
On February 17th, 2021, McAfee disclosed findings based on a 10-month long disclosure process with major video conferencing vendor Agora, Inc. As we disclosed the findings to Agora in April 2020, this lengthy disclosure timeline represents a nonstandard process for McAfee but was a joint agreement with the vendor to allow sufficient time for the development and release of a secure SDK. The release of the SDK mitigating the vulnerability took place on December 17th, 2020. Given the implications of snooping and spying on video and audio calls, we felt it was important to provide Agora the extended disclosure time. The affected users of Agora include popular voice and video messaging apps, with one notable application being the popular new iOS app known as Clubhouse.
Clubhouse Application Screenshot
Clubhouse has made headlines recently as one of the newest players in the social networking sphere, rising in popularity after a series of high-profile users including Elon Musk, Kanye West and influencers in various geographies posted about the platform. Released in April of 2020, Clubhouse quickly carved out a niche in Chinese social media as the platform to discuss sensitive social and political topics – perhaps aided by its invite-only approach to membership – and the spotlight shined on it by these key players further propelled it into viral status early this year. Perhaps unsurprisingly, the application was blocked for use in China on February 8th, 2021.
Last week, Stanford Internet Observatory (SIO) released research regarding the popular Clubhouse app’s use of Agora real-time engagement software and suggested that Agora could have provided the Chinese government access to Clubhouse user information and communications. While the details of Stanford’s disclosure focus on the audio SDK compared to our work on the video SDK, the functionality and flaw are similar to our recent disclosure, CVE-2020-25605. This includes the plaintext transmission of app ID, channel ID and token – credentials necessary to join either audio or video calls. We can confirm that Clubhouse updated to the most recent version of the Agora SDK on February 16th – just a day prior to our public disclosure.
Despite the recent noise surrounding Clubhouse, the reality is that this application is just one of many applications that leverage the Agora SDK. Among others, we investigated the social apps eHarmony, Skout, and MeetMe, along with several widely-used healthcare apps, some of which have a significantly larger user base. For example, MeetGroup (comprised of several apps) reported approximately 18 million monthly users compared to Clubhouse, which had approximately 600k total users as of December 2020.
We felt it was important to highlight these data points and are continuing to investigate these applications as well as monitor any potential instances of malicious actors exploiting this vulnerability. Given that Agora has released an updated SDK that fixes the call setup issues, vulnerable applications should have already switched to the secure calling SDK, thus protecting the sensitive audio and video call data as many claim to do. With that in mind, we decided to check back in with some of the Agora-based apps we previously investigated to confirm whether they had updated to the patched version. We were surprised to see many, as of February 18, 2020, still had not:
| App Name | Installs | App Version | App Version Date | Updated Agora SDK |
| MeetMe | 50,000,000+ | 14.24.4.2910 | 2/9/2021 | Yes |
| LOVOO | 50,000,000+ | 93.0 | 2/15/2021 | No |
| Plenty of Fish | 50,000,000+ | 4.36.0.1500755 | 2/5/2021 | No |
| SKOUT | 50,000,000+ | 6.32.0 | 2/3/2021 | Yes |
| Tagged | 10,000,000+ | 9.32.0 | 12/29/2020 | No |
| GROWLr | 1,000,000+ | 16.1.1 | 2/11/2021 | No |
| eharmony | 5,000,000+ | 8.16.2 | 2/5/2021 | Yes |
| Clubhouse | 2,000,000+ | 0.1.2.8 | 2/16/2021 | Yes |
| Practo | 5,000,000+ | 4.93 | 1/26/2021 | No |
With the context around censorship and basic privacy concerns, it will be interesting to see if these and many other apps using the vulnerable SDK update quickly, or even ever, and what kind of lasting effects these types of findings have on users’ trust and confidence in social media platforms.
For more on McAfee ATR’s research into the Agora SDK, please see our technical research blog.
For information on how users can protect themselves when using such apps, please see our consumer safety tips blog.
The post Beyond Clubhouse: Vulnerable Agora SDKs Still in Widespread Use appeared first on McAfee Blogs.
The McAfee Advanced Threat Research (ATR) team is committed to uncovering security issues in both software and hardware to help developers provide safer products for businesses and consumers. We recently investigated and published several findings on a personal robot called “temi”, which can be read about in detail here. A byproduct of our robotic research was a deeper dive into a video calling software development kit (SDK) created by Agora.io. Agora’s SDKs are used for voice and video communication in applications across multiple platforms. Several of the most popular mobile applications utilizing the vulnerable SDK included social apps such as eHarmony, Plenty of Fish, MeetMe and Skout, and healthcare apps such as Talkspace, Practo and Dr. First’s Backline. In early 2020, our research into the Agora Video SDK led to the discovery of sensitive information sent unencrypted over the network. This flaw, CVE-2020-25605, may have allowed an attacker to spy on ongoing private video and audio calls. At the time of writing, McAfee is unaware of any instances of this vulnerability being exploited in the wild. We reported this research to Agora.io on April 20, 2020 and the company, as of December 17th, 2020 released a new SDK, version 3.2.1, which mitigated the vulnerability and eliminated the corresponding threat to users.
Encryption has increasingly become the new standard for communication; often even in cases where data privacy is not explicitly sensitive. For example, all modern browsers have begun to migrate to newer standards (HTTP/2) which enforce encryption by default, a complete change from just a few years ago where a significant amount of browsing traffic was sent in clear text and could be viewed by any interested party. While the need to protect truly sensitive information such as financial data, health records, and other personally identifiable information (PII) has long been standardized, consumers are increasingly expecting privacy and encryption for all web traffic and applications. Furthermore, when encryption is an option provided by a vendor, it must be easy for developers to implement, adequately protect all session information including setup and teardown, and still meet the developers’ many use cases. These core concepts are what led us to the findings discussed in this blog.
As part of our analysis of the temi ecosystem, the team reviewed the Android application that pairs with the temi robot. During this analysis, a hardcoded key was discovered in the app.
This raised the question: What is this key and what is it used for? Thanks to the detailed logging provided by the developers, we had a place to start, https://dashboard.agora.io.
According to the website – “Agora provides the SDKs and building blocks to enable a wide range of real-time engagement possibilities” In the context of our initial robot project, it simply provides the technology required to make audio and video calls. In a broader context, Agora is used for a variety of applications including social, retail, gaming and education, among others.
Agora allows anyone to create an account and download its SDKs for testing from its website, which also provides extensive documentation. Its GitHub repositories also provide detailed sample projects on how to use the product. This is amazing for developers, but also very useful to security researchers and hackers. Using the logging comments from the above code we can look at the documentation to understand what an App ID is and what it is used for.
The last two sentences of this documentation really grabbed our attention. We had found a key which is hardcoded into an Android application that “anyone can use on any Agora SDK” and is “prudent to safeguard”.
Agora provides several different SDKs with different functionality. Since we encountered Agora through use of the video SDK, we decided to focus on only this SDK for the rest of this research. Simulating the mindset of an attacker, we began to investigate what this App ID or key could be used for. Furthermore, in the context of the video SDK, the question evolved into whether an attacker could interact with this video and audio traffic.
Since Agora provides sample projects and allows for free developer accounts, the best way to understand what potential attack vectors exists is to use these tools. Examining the GitHub example projects and the following associated documentation, we can learn exactly what is needed and how a normal user is connected to a video call.
Here we see in the example code the App ID being used to create a new “RtcEngine” object. As can be seen in the documentation, creating an RtcEngine is the foundation and first step needed to create any video call.
If we continue to examine the example code and look at the documentation’s steps for connecting to a call, we come to a function named “joinChannel”.
This function is responsible for connecting an end user to a call. In the example code, there are four parameters, three of which are hardcoded and one of which can be set to null. Without doing too much more digging, it appears that while Agora lists the App ID as important, it is not the only component needed to join a video call. An attacker would also require the values passed to the joinChannel API in order to join a call. If we assume that these values are only hardcoded for the purpose of a demo application, how would an attacker obtain the other necessary values? Code is an awesome resource, but when it comes to a network conversation the truth is in the packets. By running this example code and capturing traffic with Wireshark, we can further our understanding of how this system works.
When looking at the traffic, what immediately stands out is the values passed to joinChannel in the example code above. They are sent in plaintext across the network, in addition to the App ID needed to initiate the RtcEngine. Considering this is an example app, it is important to understand the difference between a test scenario and a production scenario. As noted in the code in Figure 5, the “token” parameter is being set to null. What is a token in this context, and would that affect the security of these parameters? We can use the Agora documentation to understand that a token is designed to be randomly generated and provide more security for a session.
With tokens being an option, it is important we see what the traffic looks like in a scenario where the token parameter is not null. The use of a token is hopefully what we find in production or at least is what is recommended in production by Agora.
Running the example application again, this time using a token and capturing traffic, we can discover that the token is also a non-issue for an attacker.
The token is sent in plaintext just like the other parameters! You may have noticed this capture does not show the App ID; in this case the App ID is still sent in plaintext, in a different packet.
Information being sent in plaintext across the network to initiate a video call is one thing, but can this actually be used by an attacker to spy on a user? Will the call support a third party? Will the user be notified of a new connection? In order to answer these questions, we can use the example applications provided by Agora to run some tests. The diagram below shows the scenario we are going to try and create for testing.
The first step for an attacker sitting on the network is to be able to identify the proper network traffic containing the sensitive information. With this information from the network packets, they can then attempt to join the call that is in progress. Using a Python framework called Scapy, we built a network layer in less than 50 lines of code to help easily identify the traffic the attacker cares about. This was done by reviewing the video call traffic and reverse engineering the protocol. Like a lot of reversing, this is done by using context clues and a lot of “guess and check”. Strings help us identify the use for certain fields and provide clues to what the fields around them might be. In some cases, fields are still unknown; however, this is normal. An attacker or researcher only needs to decipher enough of a packet to make an attack possible.
The above code identifies, parses, and displays in human readable form, only the important information in the three main packet types discovered in the Agora traffic. From here we can automate the scenario outlined in Figure 10 using Python with a few modifications to the example apps. It totally works! The demo video below shows an attacker sniffing network traffic to gather the call information and then launching their own Agora video application to join the call, completely unnoticed by normal users.
Besides using a token, were there any other security measures available to developers that might have mitigated the impact of this vulnerability? Per Agora’s documentation, the developer has the option to encrypt a video call. We also tested this, and the App ID, Channel Name, and Token are still sent in plaintext when the call is encrypted. An attacker can still get these values; however, they cannot view the video or hear the audio of the call. Despite this, the attacker can still utilize the App ID to host their own calls at the cost of the app developer. We will discuss in the next section why, even though encryption is available, it is not widely adopted, making this mitigation largely impractical.
This research started with the discovery of an App ID hardcoded into “temi”, the personal robot we were researching. Agora documents clearly on its website that this App ID should be “kept safe”, which we discovered as a vulnerability while researching temi. However, further examination shows that even if temi had kept this value safe, it is sent in cleartext over the network along with all the other values needed to join the call. So how does this impact other consumers of the Agora SDK outside of temi?
Agora’s website claims – “Agora’s interactive voice, video, and messaging SDKs are embedded into mobile, web and desktop applications across more than 1.7 billion devices globally.” To ensure our comparisons would be reasonable, we looked only at other Android applications which used the video SDK. We also focused on apps with a very large install base.
To give a quick cross-section of apps on Google Play that utilize Agora, let’s focus on MeetMe, Skout, Nimo TV, and, of course, temi. Google Play reports the number of installs at 50 million+ each for MeetMe and Skout, 10 million+ for Nimo TV and 1000+ for temi. By examining the applications’ decompiled code, we can easily determine all four of these applications have hardcoded App IDs and do not enable encryption. We see very similar code as below in all the applications:
The most important line here is the call to setEncryptionSecret which is being passed the “null” parameter. We can reference the Agora documentation to understand more about this call.
Even though the encryption functions are being called, the application developers are actually disabling the encryption based on this documentation. A developer paying close attention might ask if this is the only place the API is being called. Could it be set elsewhere? The team searched the decompiled code for all the applications reviewed and was unable to find any other instance of the API call, leading us to believe this is the only call being made. With this in mind, the cleartext traffic has a greater impact that goes well beyond a personal robot application to millions – potentially billions – of users. Without encryption enabled and the setup information passed in cleartext, an attacker can spy on a very large range of users.
Although Agora should not have been sending this sensitive information unencrypted, if it offers an encrypted traffic option, why is it not being used? This would at least protect the video and audio of the call, even though an attacker is able to join. While it is impossible to be certain, one reason might be because the Agora encryption options require a pre-shared key, which can be seen in its example applications posted on GitHub. The Agora SDK itself did not provide any secure way to generate or communicate the pre-shared key needed for the phone call, and therefore this was left up to the developers. Many calling models used in applications want to give the user the ability to call anyone without prior contact. This is difficult to implement into a video SDK post-release since a built-in mechanism for key sharing was not included. It is also worth noting that, generally, the speed and quality of a video call is harder to maintain while using encryption. These may be a few of the reasons why these application developers have chosen to not use the encryption for the video and audio. Now that the SDK properly and transparently handles encryption of call setup, developers have the opportunity to leverage a more secure method of communication for traffic. Additionally, developers still have the option to add full encryption to further protect video and audio streams.
Agora has published a list of best practices for all its developers and partners here, which does include use of encryption when possible. We generally recommend following vendors’ security best practices as they are designed to apply to the product or service directly. In this case, the vulnerability would still exist; however, its effectiveness would be extremely limited if the published best practices were followed. Although we have found Agora’s recommendations were largely not being adopted, Agora has been actively communicating with customers throughout the vulnerability disclosure process to ensure its recommended processes and procedures are widely implemented.
Privacy is always a top concern for consumers, but also remains an enticing threat vector for attackers. If we look at the two biggest apps we investigated (MeetMe and Skout), both are rated for mature audiences (17+) to “meet new people” and both advertise over 100 million users. MeetMe also mentions “flirting” on the Google Play store and its website has testimonies about people meeting the “love of their life”. Although they are not explicitly advertised as dating apps, it would be reasonable to draw the conclusion that it is at least one of their functions. In the world of online dating, a breach of security or the ability to spy on calls could lead to blackmail or harassment by an attacker. Other Agora developer applications with smaller customer bases, such as the temi robot, are used in numerous industries such as hospitals, where the ability to spy on conversations could lead to the leak of sensitive medical information.
One goal of the McAfee Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. As per McAfee’s responsible disclosure policy, McAfee ATR informed Agora as soon as the vulnerability was confirmed to be exploitable. Agora was very receptive and responsive to receiving this information and further advanced its current security capabilities by providing developers with an SDK option (version 3.2.1) to encrypt the initial call setup information, mitigating this vulnerability. We have tested this new SDK and can confirm it fully mitigates CVE-2020-25605. At the time of writing, McAfee is unaware of any instances of this vulnerability being exploited in the wild, which demonstrates another powerful success story of mitigating an issue which may have affected millions of users before it is used for malicious purposes. Our partnership with Agora resulted in the release of a more secure SDK which has empowered developers across multiple companies to produce more secure video calling applications. We strongly recommend any development team which uses the Agora SDK to upgrade to the latest version, follow Agora’s outlined best practices, and implement full encryption wherever possible.
CVE: CVE-2020-25605
CVSSv3 Rating: 7.5/6.7
CVSS String: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N/E:P/RL:O/RC:C
CVE Description: Cleartext transmission of sensitive information in Agora Video SDK prior to 3.1 allows a remote attacker to obtain access to audio and video of any ongoing Agora video call through observation of cleartext network traffic.
The post Don’t Call Us We’ll Call You: McAfee ATR Finds Vulnerability in Agora Video SDK appeared first on McAfee Blogs.
In fact, looking back at just the last 8 months of Microsoft patches, we’ve tracked at least 25 significant vulnerabilities directly related to the Windows network stack. These have ranged from DNS to NTFS, SMB to NFS and recently, several tcp/ip bugs in fragmentation and packet reassembly for IPv4 and IPv6.
That brings us to this month’s patch Tuesday, which contains several more high-profile critical vulnerabilities in tcpip.sys. We’ll focus on three of these, including 2 marked as “remote code execution” bugs, which could lead to wormability if code execution is truly possible, and a persistent denial-of-service vulnerability which could cause a permanent Blue Screen of Death on the latest versions of Windows.
There are clear similarities between all 3, indicating both Microsoft and researchers external to Microsoft are highly interested in auditing this library, and are having success in weeding out a number of interesting bugs. The following is a short summary of each bug and the progress we have made to date in analyzing them.
What is CVE-2021-24086?
The first vulnerability analyzed in this set is a Denial-of-Service (DOS) attack. Generally, these types of bugs are rather uninteresting; however, a few can have enough of an impact that although an attacker can’t get code execution, they are well worth discussing. This is one of those few. One of the things that boost this vulnerability’s impact is the fact it is internet routable and many devices using IPv6 can be directly accessible over the internet, even when behind a router. It is also worth noting that the default Windows Defender Firewall configuration does not mitigate this attack. In a worst-case scenario, an attacker could spray this attack and put it on a continuous loop to potentially cause a “permanent” or persistent DOS to a wide range of systems.
This vulnerability exists when Windows’ tcpip.sys driver attempts to reassemble fragmented IPv6 packets. As a result, this attack requires many packets to be successful. The root cause of this vulnerability is a NULL pointer dereference which occurs in Ipv6pReassembleDatagram. The crash occurs when reassembling a packet with around 0xffff bytes of extension headers. It should be impossible to send a packet with that many bytes in the extension headers according to the RFC, however this is not considered in the Ipv6pReceiveFragments function when calculating the unfragmented length. Leveraging a proof-of-concept through the Microsoft MAPP program, McAfee was easily able to reproduce this bug, demonstrating it has the potential to be seen in the wild.
What is CVE-2021-24094?
This vulnerability is classified by Remote Code Execution (RCE), though our analysis thus far, code execution comes with unique challenges. Similar to CVE-2021-24086, this issue involves IPv6 packet reassembly by the Windows tcpip.sys driver. It is different from 24086 in that it doesn’t require a large packet with extension headers, and it is not a NULL pointer dereference. Instead, it is a dangling pointer which, if the right packet data is sprayed from an attacker over IPv6, will causes the pointer to be overwritten and reference an arbitrary memory location. When the data at the pointer’s target is accessed, it causes a page fault and thus a Blue Screen of Death (BSOD). Additionally, an attacker can create persistence of the DoS by continually pointing the attack at a victim machine.
While the reproduction of this issue causes crashes on the target in all reproductions so far, it’s unclear how easy it would be to force the pointer to a location that would cause valid execution without crashing. The pointer would need to point to a paged-in memory location that had already been written with additional data that could manipulate the IPv6 reassembly code, which would likely not come from this attack alone, but may require a separate attack to do so.
What is CVE-2021-24074?
CVE-2021-24074 is a potential RCE in tcpip.sys triggered during the reassembly of fragmented IPv4 packets in conjunction with a confusion of IPv4 IP Options. During reassembly, it is possible to have two fragments with different IP Options; this is against the IPv4 standard, but Windows will proceed further, while failing to perform proper sanity checks for the respective options. This type confusion can be leveraged to trigger an Out of Bounds (OOB) read and write by “smuggling” an IP option Loose source and record route (LSRR) with invalid parameters. This option is normally meant to specify the route a packet should take. It has a variable length, starts with a pointer field, and is followed by a list of IP addresses to route the packet through.
By leveraging the type confusion, we have an invalid pointer field that will point beyond the end of the routing list provided in the packet. When the routing function Ipv4pReceiveRoutingHeader looks up the next hop for the packet, it will OOB read this address (as a DWORD) and perform a handful of checks on it. If these checks are successful, the IP stack will attempt to route the packet to its next hop by copying the original packet and then writing its own IP address in the record route. Because this write relies on the same invalid pointer value as before, this turns out to be an OOB write (beyond the end of the newly allocated packet). The content of this OOB write is the IP address of the target machine represented as a DWORD (thus, not controlled by the attacker).
Microsoft rates this bug as “Exploitation more likely”, however exploitation might not be as straightforward as it sounds. For an attack to succeed, one would have to groom the kernel heap to place a certain value to be read during the OOB read, and then make it so the OOB write would corrupt something of interest. Likely, a better exploitation primitive would need to be established first in order to successfully exploit the bug. For instance, leveraging the OOB write to corrupt another data structure that could lead to information disclosure and/or a write-what-where scenario.
From a detection standpoint, the telltale signs of an active exploitation would be fragmented packets whose IP Options vary between fragments. For instance, the first fragment would not contain an LSRR option, while the second fragment would. This would likely be accompanied by a heavy traffic meant to shape the kernel heap.
Similarities and Impact Assessment
There are obvious similarities between all three of these vulnerabilities. Each is present in the tcpip.sys library, responsible for parsing IPv4 and IPv6 traffic. Furthermore, the bugs all deal with packet reassembly and the RCE vulnerabilities leverage similar functions for IPv4 and IPv6 respectively. Given a combination of public and Microsoft-internal attribution, it’s clear that researchers and vendor alike are chasing down the same types of bugs. Whenever we see vulnerabilities in network stacks or Internet-routed protocols, we’re especially interested to determine difficulty of exploitation, wormability, and impact. For vulnerabilities such as the RCEs above, a deep dive is essential to understand the likelihood of these types of flaws being built into exploit kits or used in targeted attacks and are prime candidates for threat actors to weaponize. Despite the real potential for harm, the criticality of these bugs is somewhat lessened by a higher bar to exploitation and the upcoming patches from Microsoft. We do expect to see additional vulnerabilities in the TCP/IP stack and will continue to provide similar analysis and guidance. As it is likely to take some time for threat actors to integrate these vulnerabilities in a meaningful way, the best course of action, as always, is widespread mitigation via patching.
The post Researchers Follow the Breadcrumbs: The Latest Vulnerabilities in Windows’ Network Stack appeared first on McAfee Blogs.
McAfee’s Advanced Threat Research team just completed its second annual capture the flag (CTF) contest for internal employees. Based on tremendous internal feedback, we’ve decided to open it up to the public, starting with a set of challenges we designed in 2019.
We’ve done our best to minimize guesswork and gimmicks and instead of flashy graphics and games, we’ve distilled the kind of problems we’ve encountered many times over the years during our research projects. Additionally, as this contest is educational in nature, we won’t be focused as much on the winners of the competition. The goal is for anyone and everyone to learn something new. However, we will provide a custom ATR challenge coin to the top 5 teams (one coin per team). All you need to do is score on 2 or more challenges to be eligible. When registering for the contest, make sure to use a valid email address so we can contact you.
The ATR CTF will open on Friday, February 5th at 12:01pm PST and conclude on Thursday, February 18th, at 11:59pm PST.
Click Here to Register!
If you’ve never participated in a CTF before, the concept is simple. You will:
NOTE: The format of all flags is ATR[], placing the flag, between the square brackets. For example: ATR[1a2b3c4d5e]. The flag must be submitted in full, including the ATR and square bracket parts.
The harder the challenge, the higher the points! Points range from 100 to 500. All CTF challenges are designed to practice real-world security concepts, and this year’s categories include:
The contest is set up to allow teams as groups or individuals. If you get stuck, a basic hint is available for each challenge, but be warned – it will cost you points to access the hint and should only be used as a last resort.
McAfee employees are not eligible for prizes in the public competition but are welcome to compete.
When registering, please use a valid email address, for any password resets and to be contacted for prizes. We will not store or save any email addresses or contact you for any non-contest related reasons.
Please wait until the contest ends to release any solutions publicly.
No cooperation between teams with independent accounts. Sharing of keys or providing/revealing hints to other teams is cheating, please help us keep this contest a challenge for all!
Please refrain from attacking the competition infrastructure. If you experience any difficulties with the infrastructure itself, questions can be directed to the ATR team using the email in the Contact Us section. ATR will not provide any additional hints, feedback, or clues. This email is only for issues that might arise, not related to individual challenges.
Absolutely no sabotaging of other competing teams, or in any way hindering their independent progress.
No brute forcing of challenge flag/ keys against the scoring site is accepted or required to solve the challenges. You may perform brute force attacks if necessary, on your own endpoint to determine a solution if needed. If you’re not sure what constitutes a brute force attack, please feel free to contact us.
DoSing the Capture–the–Flag (CTF) platform or any of the challenges is forbidden
Additional rules are posted within the contest following login and should be reviewed by all contestants prior to beginning.
Many of these challenges are designed with Linux end-users in mind. However, if you are a Windows user, Windows 10 has a Linux subsystem called ‘WSL’ that can be useful, or a Virtual Machine can be configured with any flavor of Linux desired and should work for most purposes.
Happy hacking!
Find a list of useful tools and techniques for CTF competitions. While it’s not exhaustive or specifically tailored to this contest, it should be a useful starting point to learn and understand tools required for various challenges.
While it may be difficult for us to respond to emails, we will do our best – please use this email address to reach us with infrastructure problems, errors with challenges/flag submissions, etc. We are likely unable to respond to general questions on solving challenges.
How much do you know about McAfee’s industry-leading research team?
ATR is a team of security researchers that deliver cutting-edge vulnerability and malware research, red teaming, operational intelligence and more! To read more about the team and some of its highlighted research, please follow this link to the ATR website.
By participating in the contest, you agree to be bound to the Official Rules and to release McAfee and its employees, and the hosting organization from any and all liability, claims or actions of any kind whatsoever for injuries, damages or losses to persons and property which may be sustained in connection with the contest. You acknowledge and agree that McAfee et al is not responsible for technical, hardware or software failures, or other errors or problems which may occur in connection with the contest. By participating you allow us to publish your name. The collection and use of personal information from participants will be governed by the McAfee Private Notice.
The post McAfee ATR Launches Education-Inspired Capture the Flag Contest! appeared first on McAfee Blogs.
Depending on your life experiences, the phrase (or country song by Eric Church) “two pink lines” may bring up a wide range of powerful emotions. I suspect, like many fathers and expecting fathers, I will never forget the moment I found out my wife was pregnant. You might recall what you were doing, or where you were and maybe even what you were thinking. As a professional ethical hacker, I have been told many times – “You just think a little differently about things.” I sure hope so, since that’s my day job and sure enough this experience wasn’t any different. My brain immediately asked the question, “How am I going to ensure my family is protected from a wide range of cyberthreats?” Having a newborn opens the door to all sorts of new technology and I would be a fool not to take advantage of all devices that makes parenting easier. So how do we do this safely?
The security industry has a well-known concept called the “principle of least privilege. “This simply means that you don’t give a piece of technology more permissions or access than it needs to perform its primary function. This can be applied well beyond just technology that helps parents; however, for me it’s of extra importance when we talk about our kids. One of the parenting classes I took preparing for our newborn suggested we use a baby tracking phone app. This was an excellent idea, since I hate keeping track of anything on paper. So I started looking at a few different apps for my phone and discovered one of them asked for permission to use “location services,” also known as GPS, along with access to my phone contacts. This caused me to pause and ask: Why does an app to track my baby’s feeding schedule need to know where I am? Why does it need to know who my friends are? These are the types of questions parents should consider before just jumping into the hottest new app. For me, I found a different, less popular app which has the same features, just with a little less access.
It’s not always as easy to just “find something else.” In my house, “if momma ain’t happy, nobody is happy.” So, when my wife decided on a specific breast pump that came with Bluetooth and is internet enabled, that’s the one she is going to use. The app backs up all the usage data to a server in the cloud. There are many ways that this can be accomplished securely, and it is not necessary a bad feature, but I didn’t feel this device benefited from being internet connected. Therefore, I simply lowered its privileges by not allowing it internet access in the settings on her phone. The device works perfectly fine, she can show the doctor the data from her phone, yet we have limited our online exposure and footprint just a little more. This simple concept of least privilege can be applied almost everywhere and goes a long way to limiting your exposure to cyber threats.
I think one of the most sought after and used products for new parents is the baby monitor or baby camera. As someone who has spent a fair amount of time hacking cameras (or cameras on wheels) this was a large area of concern for me. Most cameras these days are internet connected and if not, you often lose the ability to view the feed on your phone, which is a huge benefit to parents. So how, as parents, do we navigate this securely? While there is no silver bullet here, there are a few things to consider. For starters, there are still many baby cameras on the market that come with their own independent video screen. They generally use Wi-Fi and are only accessible from home. If this system works for you, use it. It is always more secure to have a video system which is not externally accessible. If you really want to be able to use your phone, consider the below.
Most parents, especially new ones, like to ensure that anyone that watches their children is thoroughly vetted. There are a ton of services out there to do this for babysitters and nannies, however it’s not always as easy for vetting the companies that create the devices we put in our homes. So how do we determine what is safe? My father used to tell me: “It’s how we respond to our mistakes that makes the difference.” When researching a company or device, should you find that the device has been found to have a vulnerability, often the response time and accountability from the vendor can tell you if it’s a company you should be investing in. Some things to look for include:
These answers can often be discovered on a company’s website or in release notes, which are generally attached to an update of a piece of software. Take a minute to read the notes and see if the company is making security updates. You don’t need to understand all the details, just knowing they take security seriously enough to update frequently is important. This can help tip the scales when deciding between devices or apps.
Through my preparation for becoming a new parent, I constantly read in books and was told by professionals, “Remember, you can do this!” Cybersecurity in the context of being a parent is no different. Every situation is different, and it is important to do what works with you and your family. As parents, we shouldn’t be afraid to use all the cool new gadgets that are emerging on the market, but instead educate ourselves on how to limit our risk. Which features do I need, which ones can I do without? Remember always follow a vendor’s recommendations and best practices, and of course remember to breathe!
The post Two Pink Lines appeared first on McAfee Blogs.
Today, we celebrate the life and legacy of Dr. Martin Luther King Jr. Dr. King diligently dedicated his life to dismantling systemic racism affecting marginalized groups and leading a peaceful movement to promote equality for all Americans, irrespective of color and creed. He leaves behind a legacy of courage, strength, perseverance, and a life-long dedication to pursuing a fair and just world.
At McAfee, we honor the diverse voices which make up our company and encourage every team member to bring their authentic selves to the workplace. We believe that our collective voice and action can make a difference in creating a more equal and unified world.
On this day, we commemorate MLK by honoring the man behind the message of equality. Members of the McAfee African Heritage Community share their perspectives on the impact that Martin Luther King Jr. has had on their lives and what this day means to them.
Alexus, Software Sales Engineer
When I think about what Martin Luther King Jr. Day means to me, I think of it as a time to reflect and think about the progress we have made as citizens of this country. We have made great strides, but there is much more that needs to be done for equality and justice.
I honor Martin Luther King Jr. by being of service to others around me.
I celebrate Martin Luther King Jr. Day by using my voice to uplift others.
Martin Luther King Jr. inspires me to be a man of excellence and courage.
Denise, People Operations Program ManagerFor me, Martin Luther King Jr. Day is a reminder of how far we’ve come, and how far we still have to go as a society – especially in today’s time of social unrest. Some of Dr. King’s most poignant quotes are still so applicable and impactful today.
For example – “People fail to get along because they fear each other; they fear each other because they don’t know each other; they don’t know each other because they have not communicated with each other.”
I honor Martin Luther King Jr. by doing what I can to have a positive impact on the lives of others.
I celebrate Martin Luther King Jr. Day by looking for areas to give back and serve.
Martin Luther King Jr. inspires me to do better, be better and influence the world around me accordingly.
Kristol, Global Sales Operations ManagerMLK Jr. Day is a reminder of the influence ONE person can have on people, perspectives, and shaping a platform. It means that my voice matters and that I have a right to live my dream—a dream that we continue to fight for today.
I honor Martin Luther King Jr. by never giving up on my dreams.
I celebrate Martin Luther King Jr. Day by freely bringing my authentic self to work, home and the community every day.
Martin Luther King Jr. inspires me to be a courageous, strategic and compassionate leader.
Le Var, Customer Success Manager
MLK Day always drives me to think about Dr. King’s dream and the work of the civil rights movement. I then look for ways I can make an impact in my local community to continue the work of those before me.
I honor Martin Luther King Jr. by passing the baton and sharing his dream to the next generation, molding my children to understand the past, and continuing to push Dr. King’s dream for future decades.
I celebrate Martin Luther King Jr. Day by researching African American history in an effort to broaden my own knowledge and share information I’ve learned with my peers.
Martin Luther King Jr. inspires me to make a positive impact on the community I live in. Much like Dr. King, I am one man who strives to be the dream of my ancestors. Individually, I can move boulders, but collectively, we can move mountains.
Lynne, EVP of Enterprise Global Sales and Marketing and Executive Sponsor
Martin Luther King Jr. Day means a chance to celebrate the legacy of a man who was a pivotal leader of the civil rights movement, hope and healing. Though his life was a short one, his impact was great, and there are so many lessons to learn from the words that MLK Jr. has left with us.
I honor Martin Luther King Jr. by showing up as an ally who’s ready to listen and take action.
I celebrate Martin Luther King Jr. Day by reflecting on the wise lessons shared by Martin Luther King Jr. and making it a point to have conversations about his impact.
Martin Luther King Jr. inspires me to use my voice to encourage conversation, connection and community.
Dr. Martin Luther King Jr.’s Biography
5 of Martin Luther King Jr.’s Most Memorable Speeches
MLK Day Playlist: 10 Songs in Honor of Dr. King
Interested in joining a company that celebrates diverse voices and promotes meaningful change in our world? Explore our career opportunities. Subscribe to job alerts.
The post Honoring Martin Luther King Jr.’s Legacy with McAfee’s African Heritage Community appeared first on McAfee Blogs.
