Vulnerability Discovery in Open Source Libraries: Analyzing CVE-2020-11863

Open Source projects are the building blocks of any software development process. As we indicated in our previous blog, as more and more products use open source code, the increase in the overall attack surface is inevitable, especially when open source code is not audited before use. Hence it is recommended to thoroughly test it for potential vulnerabilities and collaborate with developers to fix them, eventually mitigating the attacks. We also indicated that we were researching graphics libraries in Windows and Linux, reporting multiple vulnerabilities in Windows GDI as well as Linux vector graphics library libEMF. We are still auditing many other Linux graphics libraries since these are legacy code and have not been strictly tested before.

In part 1 of this blog series, we described in detail the significance of open source research, by outlining the vulnerabilities we reported in the libEMF library. We also highlighted the importance of compiling the code with memory sanitizers and how it can help detect a variety of memory corruption bugs. In summary, the Address Sanitizer (ASAN) intercepts the memory allocation / deallocation functions like malloc () / free() and fills out the memory with the respective fill bytes (malloc_fill_byte / free_fill_byte). It also monitors the read and write to these memory locations, helping detect erroneous access during run time.

In this blog, we provide a more detailed analysis for one of the reported vulnerabilities, CVE-2020-11863, which was due to the use of uninitialized memory. This vulnerability is related to CVE-2020-11865, a global object vector out of bounds memory access in the GlobalObject::Find() function in libEMF. However, the crash call stack turned out to be different, which is why we decided to examine this further and produce this deep dive blog.

The information provided by the ASAN was sufficient to reproduce the vulnerability crash outside of the fuzzer. From the ASAN information, the vulnerability appeared to be a null pointer dereference, but this was not the actual root cause, as we will discuss below.

Looking at the call stack, it appears that the application crashed while dynamically casting the object, for which there could be multiple reasons. Out of those possible reasons that seem likely, either the application attempted to access the non-existent virtual table pointer, or the object address returned from the function was a wild address accessed when the application crashed. Getting more context about this crash, we came across an interesting register value while debugging. Below shows the crash point in the disassembly indicating the non-existent memory access.

If we look at the state of the registers at the crash point, it is particularly interesting to note that the register rdi has an unusual value of 0xbebebebebebebebe. We wanted to dig a little deeper to check out how this value got into the register, resulting in the wild memory access. Since we had the source of the library, we could check right away what this register meant in terms of accessing the objects in memory.

Referring to the Address Sanitizer documentation, it turns out that the ASAN writes 0xbe to the newly allocated memory by default, essentially meaning this 64-bit value was written but the memory was not initialized. The ASAN calls this as the malloc_fill_byte. It also does the same by filling the memory with the free_fill_byte when it is freed. This eventually helps identify memory access errors.

This nature of the ASAN can also be verified in the libsanitizer source here. Below is an excerpt from the source file.

Looking at the stack trace at the crash point as shown below, the crash occurred in the SelectObject() function. This part of the code is responsible for processing the EMR_SELECTOBJECT record structure of the Enhanced Meta File (EMF) file and the graphics object handle passed to the function is 0x80000018. We want to investigate the flow of the code to check if this is something which comes directly from the input EMF file and can be controlled by an attacker.

In the SelectObject() function, while processing the EMR_SELECTOBJECT record structure, the handle to the GDI object is passed to GlobalObjects.find() as shown in the above code snippet, which in turn accesses the global stock object vector by masking the higher order bit from the GDI object handle and converting it into the index, eventually returning the stock object reference from the object vector using the converted index number. Stock object enumeration specifies the indexes of predefined logical graphics objects that can be used in graphics operations documented in the MS documentation. For instance, if the object handle is 0x8000018, this will be ANDed with 0x7FFFFFFF, resulting in 0x18, which will be used as the index to the global stock object vector. This stock object reference is then dynamically cast into the graphics object, following which EMF::GRAPHICSOBJECT member function getType ( ) is called to determine the type of the graphics object and then, later in this function, it is again cast into an appropriate graphics object (BRUSH, PEN, FONT, PALETTE, EXTPEN), as shown in the below code snippet.

EMF::GRAPHICSOBJECT is the class derived from EMF::OBJECT and the inheritance diagram of the EMF::OBJECT class is as shown below.

However, as mentioned earlier, we were interested in knowing if the object handle, passed as an argument to the SelectObject function, can controlled by an attacker. To be able to get context on this, let us look at the format of the EMR_SELECTOBJECT record as shown below.

As we notice here, ihObject is the 4-byte unsigned integer specifying the index to the stock object enumeration. In this case the stock object references are maintained in the global objects vector. Here, the object handle of 0x80000018 implies that index 0x18 will be used to access the global stock object vector. If, during this time, the length of the object vector is less then 0x18 and the length check is not done prior to accessing the object vector, it will result in out of bounds memory access.

Below is the visual representation of processing the EMR_SELECTOBJECT metafile record.

While debugging this issue, we enable a break point at GlobalObjects.find () and continue until we have object handle 0x80000018; essentially, we reach the point where the above highlighted EMR_SELECTOBJECT record is being processed. As shown below, the object handle is converted into the index (0x18 = 24) to access the object vector of size (0x16 = 22), resulting into out of bounds access, which we reported as CVE-2020-11865.

Further stepping into the code, it enters the STL vector library stl_vector.h which implements the dynamic expansion of the std::vectors. Since the objects vector at this point of time has only 22 elements, the STL vector will expand the vector to the size indicated by the parameter highlighted, accessing the vector by passed index, and will return the value at that object reference, as shown in the below code snippet, which comes out to be 0xbebebebebebebebe as filled by the ASAN.

The code uses the std:allocator to manage the vector memory primarily used for memory allocation and deallocation. On further analysis, it turns out that the value returned, 0xbebebebebebebebe in this case, is the virtual pointer of the non-existent stock object, which is dereferenced during dynamic casting, resulting in a crash.

As mentioned in our earlier blog, the fixes to the library have been released in a subsequent version, available here.

Conclusion

While using third party code in products certainly saves time and increases development speed, it potentially comes with an increase in the volume of vulnerabilities, especially when the code remains unaudited and integrated into products without any testing. It is extremely critical to perform fuzz testing of the open source libraries used, which can help in discovering vulnerabilities earlier in the development cycle and provides an opportunity to fix them before the product is shipped, consequently mitigating attacks. However, as we emphasized in our previous blog, it is critical to strengthen the collaboration between vulnerability researchers and the open source community to continue responsible disclosures, allowing the maintainers of the code to address them in a timely fashion.

The post Vulnerability Discovery in Open Source Libraries: Analyzing CVE-2020-11863 appeared first on McAfee Blogs.

How Piyush’s remarkable efforts ignited a larger impact of giving back

At McAfee, we support team members who are passionate about giving back. You are encouraged and empowered to make a substantial impact in improving our community and volunteering to help others. 

Piyush, a Software architect in our Bangalore office, is a team member particularly passionate about his community and has dedicated countless hours volunteering at the Sheila Kothavala Institute for the Deaf (SKID).  

Two years ago, his impact was multiplied when he shared his volunteer story during McAfee’s Social Initiative Contest (SIC), a program that contributes resources to the causes important to select employees who volunteer for non-governmental organizations (NGO). 

Moved by Piyush’s story, the judges funded his program for two years in a row! Funding enhanced infrastructure of a special school for hearing impaired kids and provided a tactile library that helps visually impaired students see the world through touch. 

We asked Piyush four questions to learn more. 

How did you get involved? 

I’m a son of educators. My father was a principal and my mother was a university senior lecturer. The importance of educational success runs deep for me. Seven years ago, I found my own educational calling when I was introduced to the Sheila Kothavala Institute for the Deaf  (SKID), an organization that supports the education of differently-abled students and equips them to successfully graduate high school. 

How often do you volunteer? 

What started as a weekend volunteer endeavor soon grew into an every-morning commitment. Before going into work at McAfee, I dedicate an hour each morning teaching math and volunteering with students at SKID.  

What has helped you the most in your volunteer journey? 

Figuring out how to communicate with hearing–impaired kids was a challenge for me. However, the immense support I received from the kids helped to relieve a lot of the pressure. I started to learn sign language along with them and became more effective at teaching. Spending time every day with these kids has motivated me in unexpected ways. Not only do I want to do as much as I can for them, but I also find myself more engaged at work. I’m thankful McAfee supports our passions in and out of the office.

Describe how your involvement evolved with SKID. What do you hope to accomplish in the future? 

First, I want to thank McAfee for their encouragement as I can take my volunteer activities to greater heights and accomplish even more through their support. With the funds McAfee awarded, I was able to establish a complete science lab and build an interactive curriculum that complements day-to-day learning, procure games catered towards kids with special needs, and build a tactile library for visually impaired students. 

After volunteering seven years with hearing-impaired students, this year, I’ve taken it upon myself to work more with the visually impaired. The joy on the faces of these kids continues to motivate me to do even more! 

Piyush is a stunning example of how one person’s selfless contributions have the power to inspire others and spark change on a large scale. He continues to inspire, not just through his unrelenting dedication to helping others, but through his words by encouraging others to take simple steps in giving back.

Looking to work for a company that supports the extraordinary contributions of their team members? Search our job opportunities. 

The post How Piyush’s remarkable efforts ignited a larger impact of giving back appeared first on McAfee Blogs.

Securing Space 4.0 – One Small Step or a Giant Leap? Part 1

McAfee Advanced Threat Research (ATR) is collaborating with Cork Institute of Technology (CIT) and its Blackrock Castle Observatory (BCO) and the National Space Center (NSC) in Cork, Ireland

The essence of Space 4.0 is the introduction of smaller, cheaper, faster-to-the-market satellites in low-earth-orbit into the value chain and the exploitation of the data they provide. Space research and communication prior to Space 4.0 was primarily focused on astronomy and limited to that of governments and large space agencies. As technology and society evolves to consume the “New Big Data” from space, Space 4.0 looks set to become the next battleground in the defense against cybercriminals. Space 4.0 data can range from earth observation sensing to location tracking information and applied across many vertical uses cases discussed later in this blog. In the era of Space 4.0 the evolution of the space sector is rapidly changing with a lower cost of launching, combined with public and private partnerships that open a whole new dimension of connectivity. We are already struggling to secure our data on earth, we must now understand and secure how our data will travel through space constellations and be stored in cloud data centers on earth and in space.

Low Earth Orbit (LEO) satellites are popular for scientific usage but how secure are they? The Internet of Things (IoT) introduced a myriad of insecure devices onto the Internet due to the low cost of processors and high-speed connectivity, but the speed in its adoption resulted in a large fragmentation of insecure hardware and software across business verticals.

Space 4.0 is now on course for a similar rapid adoption with nanosats as we prepare to see a mass deployment of cheap satellites into LEO. These small satellites are being used across government, academic and commercial sectors for different use cases that require complex payloads and processing. Many nanosats can coexist on a single satellite. This means that the same satellite backbone circuit infrastructure can be shared, reducing build and launch costs and making space data more accessible.

To date, satellites have typically been relay type devices repeating signals to and from different locations on earth in regions with poor internet connectivity, but that is all set to change with a mass deployment of smarter satellite devices using inter-satellite links (ISL) in  constellations like Starlink which aim to provide full high speed broadband global coverage. As the Space 4.0 sector is moving from private and government sectors to general availability, this makes satellites more accessible from a cost perspective, which will attract threat actors other than nation states, such as cyber criminals. Space 4.0 also brings with it new service delivery models such as Ground Station as a Service (GSaaS) with AWS and Azure Orbital and Satellite as a Service (SataaS). With the introduction of these, the satellite will become another device connecting to the cloud.

In our research we analyze the ecosystem to understand the latest developments and threats in relation to cybersecurity in space and whether we are ready to embrace Space 4.0 securely.

Space 4.0 Evolution

What is the Industrial 4^th Revolution? The original industrial revolution started with the invention of steam engines then electricity, computers and communication technology. Industry 4.0 is about creating a diverse, safe, healthy, just world with clean air, water, soil and energy, as well as finding a way to pave the path for the innovations of tomorrow.

The first space era, or Space 1.0, was the study of astronomy, followed by the Apollo moon landings and then the inception of the International Space Station (ISS). Space 4.0  is analogous to Industry 4.0, which is considered as the unfolding fourth industrial revolution of manufacturing and services. Traditionally, access to space has been the domain of governments and large space agencies (such as NASA or the European Space Agency) due to the large costs involved in the development, deployment and operation of satellites. In recent years, a new approach to using space for commercial, economic and societal good has been driven by private enterprises in what is termed New Space. When combined with the more traditional approach to space activity, the term “Space 4.0” is used. Space 4.0 is applicable across a wide range of vertical domains, including but not limited to:

• Ubiquitous broadband
• Autonomous vehicles
• Earth observation
• Disaster mitigation/relief
• Human spaceflight
• Exploration

Cyber Threat Landscape Review

The Cyber Threat Landscape has evolved greatly over the past 20 years with the convergence of Information Technology (IT), Operational Technology (OT) and IoT. Protecting consumers, enterprises and critical infrastructure with the rapid parallel innovation of technology and cybercriminals is a constant challenge. While technology and attacks evolve rapidly the cybercriminal motive remains a constant; make money and maximize profit by exploiting a combination of users and technology.

Cybercriminals have much more capabilities now than they did 10 years ago due to the rise of Cybercrime as a Service (CaaS). Once an exploit for a vulnerability has been developed, it can then be weaponized into an exploit kit or ransomware worm, such as WannaCry. Cybercriminals will follow the path of least resistance to achieve their goal of making money.

Nearly every device class across the business verticals, ranging from medical devices to space Very-small-aperture terminals (VSAT), have been hacked by security researchers, as evident from Blackhat and Defcon trends.

From a technology stack perspective (hardware and software) there have been vulnerabilities discovered and exploits developed across all layers where we seek to establish some form of trustworthiness when connected to the internet; browsers, operating systems, protocols, hypervisors, enclaves, cryptographic implementations, system on chips (SoC) and processors.

Not all these vulnerabilities and exploits become weaponized by cybercriminals, but it does highlight the fact that the potential exists. Some notable weaponized exploits are:

1. Stuxnet worm
2. WannaCry ransomware worm
3. Triton malware
4. Mirai Botnet

Some recent major industry vulnerabilities were: BlueKeep (Windows RDP Protocol), SMBGhost (Windows SMB Protocol), Ripple20 (Treck embedded TCP/IP library), Urgent 11 (VxWorks TCP/IP library), Heartbleed (OpenSSL library), Cloudbleed (Cloudflare), Curveball (Microsoft Crypto API), Meltdown and Spectre (Processor side channels).

Cybercriminals will adapt quickly to maximize their profit as we saw with the COVID-19 pandemic and the mass remote workforce. They will quickly understand the operating environment changes and how they can reach their goals by exploiting users and technology, whichever is the weakest link. The easiest entry point into an organization will be through identity theft or weak passwords being used in remote access protocols such as RDP.

Cybercriminals moved to the Dark Web to hide identity and physical location of servers or using bullet-proof providers to host their infrastructure. What if these services are hosted in space? Who is the legal entity and who is responsible?

McAfee Enterprise Supernova Cloud analysis reports that:

• Nearly one in 10 files shared in the cloud with sensitive data have public access, an increase of 111% year over year
• One in four companies have had their sensitive data downloaded from the cloud to an unmanaged personal device, where they cannot see or control what happens to the data
• 91% of cloud services do not encrypt data at rest
• Less than 1% of cloud services allow encryption with customer-managed keys

The transition to the cloud, when done securely, is the right business decision. However, when not done securely it can leave your services and data/data lakes accessible to the public through misconfigurations (shared responsibility model), insecure APIs, and identity and access management issues. Attackers will always go for the low hanging fruit such as open AWS buckets and credentials through vendors in the supply chain.

One of the key initiatives, and now industry benchmark, is the MITRE ATT&CK framework which enumerates the TTPs from real word incidents across Enterprise (Endpoint and Cloud), Mobile and ICS. This framework has proved to be very valuable in enabling organizations to understand adversary TTPs and the corresponding protect, detect and response controls required in their overall defense security architecture. We may well see a version of MITRE ATT&CK evolve for Space 4.0.

Space Cyber Threat Landscape Review

Threat actors know no boundaries as we have seen criminals move from traditional crime to cybercrime using whatever means necessary to make money. Likewise, technology communication traverses many boundaries across land, air, sea and space. With the reduced costs to entry and the commercial opportunities with Space 4.0 big data, we expect to see cybercriminals innovating within this huge growth area. The Cyber Threat Landscape can be divided into vulnerabilities discovered by security researchers and actual attacks reported in the wild. This allows us to understand the technologies within the space ecosystem that are known to contain vulnerabilities and what capabilities threat actors have and are using in the wild.

Vulnerabilities discovered to date have been within VSAT terminal systems and intercepting communications. There have been no vulnerabilities disclosed on actual satellites from figure 1 below.

Figure 1 – Security Researcher space vulnerability disclosures

To date, satellites have mostly been controlled by governments and the military so little information is available as to whether an actual satellite has been hacked. We do expect to see that change with Space 4.0 as these satellites will be more accessible from a hardware and software perspective to do security analysis. Figure 2 below highlights reported attacks in the wild

Figure 2 – Reported Attacks in the Wild

In McAfee’s recent threat research, “Operation North Star”, we observed an increase in malicious cyber activity targeting the Aerospace and Defense industry. The objective of these campaigns was to gather information on specific programs and technologies.

Since the introduction of the cloud, it appears everything has become a device that interacts with a service. Even cybercriminals have been adapting to the service model. Space 4.0 is no different as we start to see the adoption of the Ground Station as a Service (GSaaS) and Satellite as a Service (SataaS) models per figure 3 below. These services are opening in the space sector due to the acceleration of vendors into Space 4.0 to help keep their costs down. Like any new ecosystem this will bring new attack surfaces and challenges which we will discuss in the Threat Modelling section.

Figure 3 – New Devices and Services for Space 4.0

So, with the introduction of cheap satellites using commercial off-the-shelf (COTS) components and new cloud services is it just a matter of time before we see mass satellite attacks and compromise?

Space 4.0 Data Value

The global space industry grew at an average rate of 6.7% per year between 2005 and 2017 and is projected to rise from its current value of $350 billion to $1.3 trillion per annum by 2030. This rise is driven by new technologies and business models which have increased the number of stakeholders and the application domains which they service in a cost-effective way. The associated increase in data volume and complexity has, among other developments, resulted in increasing concerns over the security and integrity of data transfer and storage between satellites, and between ground stations and satellites.

The McAfee Supernova report shows that data is exploding out of enterprises and into the cloud. We are now going to see the same explosion from Space 4.0 to the cloud as vendors race to innovate and monetize data from low cost satellites in LEO.

According to Microsoft the processing of data collected from space at cloud-scale to observe the Earth will be “instrumental in helping address global challenges such as climate change and furthering of scientific discovery and innovation”. The value of data from space must be viewed from the perspective of the public and private vendors who produce and consume such data. Now that satellite launch costs have reduced, producing this data becomes more accessible to commercial markets, so we are going to see much innovation in data analytics to improve our lives, safety and preservation of the earth. This data can be used to improve emergency response times to save lives, monitoring illegal trafficking, aviation tracking blind spots, government scientific research, academic research, improving supply chains and monitoring the earth’s evolution, such as climate change effects. Depending on the use case, this data may need to be confidential, may have privacy implications when tracking and may have substantial value in the context of new markets, innovation and state level research. It is very clear that data from space will have much value as new markets evolve, and cybercriminals will most certainly target that data with the intent to hold organizations to ransom or sell data/analytics innovation to competitors to avoid launch costs. Whatever the use case and value of the data traveling through space may be, we need to ensure that it moves securely by providing a trustworthy end to end ecosystem.

As we progress towards the sixth digital era, our society, lives and connectivity will become very dependent on off-planet data and technology in space, starting with SataaS.

In Part 2 we will discuss remote computers in Space, the Space 4.0 threat model and what we must do to secure Space 4.0 moving forward.

McAfee would like to thank Cork Institute of Technology (CIT) and their Blackrock Castle Observatory (BCO) and the National Space Center (NSC) in Cork, Ireland for their collaboration in our mission to securing Space 4.0.

The post Securing Space 4.0 – One Small Step or a Giant Leap? Part 1 appeared first on McAfee Blogs.

Securing Space 4.0 – One Small Step or a Giant Leap? Part 2

McAfee Advanced Threat Research (ATR) is collaborating with Cork Institute of Technology (CIT) and its Blackrock Castle Observatory (BCO) and the National Space Center in Cork, Ireland

In the first of this two-part blog series we introduced Space 4.0, its data value and how it looks set to become the next battleground in the defense against cybercriminals. In part two we discuss the architectural components of Space 4.0 to threat model the ecosystem from a cybersecurity perspective and understand what we must do to secure Space 4.0 moving forward.

Nanosats: Remote Computers in Space

A satellite is composed of a payload and a bus. The payload is the hardware and software required for the mission or satellite’s specific function, such as imaging equipment for surveillance. The bus consists of the infrastructure or platform that houses the payload, such as thermal regulation and command and control. Small satellites are space craft typically weighing less than 180 kilograms and, within that class of satellites, is what we call nanosatellites or nanosats which typically weigh between 1-10 kilograms. Cubesats are a class of nanosat so you will often hear the term used interchangeably, and for the context of Space 4.0 security, we can assume they are the same device. Nanosats significantly reduce launch costs due to their small size and the fact that many of these devices can be mounted on board a larger single satellite for launch.

Commercial off-the-shelf (COTS) Cubesats typically use free open source software such as FreeRTOS or KubOS for the on-board operating system. However, other systems are possible, with drivers available for most of the hardware on Linux and Windows OS. KubOS is an open source flight software framework for satellites and has cloud-based mission control software, Major Tom, to operate nanosats or a constellation. We mention KubOS here as it is a good example of what the current Space 4.0 operating model looks like today. While we have not reviewed KubOS from a security perspective, developing a secure framework for satellites is the right path forward, allowing mission developers to focus on the payload.

Some of the use cases available with Cubesats are:

1. File transfers
2. Remote communication via uplink/downlink
3. Intra-satellite and inter-satellite communications
4. Payload services such as camera and sensors telemetry
5. Software Updates

KubOS is “creating a world where you can operate your small satellite from your web browser or iPhone”. KubOS’ objective is to allow customers to send bits and not rockets to space and it is defining a new era of software-designed satellites. The satellite model is changing from relay type devices to remote computers in space using COTS components and leveraging TCP/IP routing capabilities. This model shift also means that there is more software executing on these satellites and more complex payload processing or interaction with the software stack and hence more attack surface.

To date, attacks on satellite systems from a cybersecurity perspective have typically been in the context of VSAT terminals, eavesdropping and hijacking. While there have been vulnerabilities found in the VSAT terminal software and its higher-level custom protocols, there seems to have been no focus and vulnerabilities discovered within the network software stack of the satellite itself. This may be since satellites are very expensive, as well as closed source, so not accessible to security researchers or cybercriminals, but this security by obscurity will not provide protection with the new era of nanosats. Nanosats use COTS components which will be accessible to cybercriminals.

Due to the closed nature of satellites there has not been much published on their system hardware and software stack. However, the Consultative Committee for Space Data Systems (CCSDS), which develops standards and specifications including protocols for satellite communications, does give some insight. The CCSDS technical domains are:

1. Space Internetworking Services
2. Mission Ops. And Information Management Services
3. Spacecraft Onboard Interface Services
4. System Engineering
5. Cross Support Services
6. Space Link Services

The CCSDS standards are divided into color codes to represent recommended standards and practices versus informational and experimental. This is a very large source of data communications for satellite designers to aid them in a reference for implementation. However, as we have observed over the cyber threat landscape of the past few decades, secure standards and specifications for hardware, software and protocols do not always translate to secure implementation. The CCSDS defines a TCP/IP stack suitable for transmission over space datalinks as per figure 1 below. Satellites that become more connected, just like any other device on the internet, their network and protocol software stack will become more accessible and targeted. As we discussed in part 1 <insert link> of our Space 4.0 blog series, there have been many TCP/IP and remote protocol related vulnerabilities in both embedded devices and even state of the art operating systems such as Windows 10. The TCP/IP stack and remote protocol implementations are a common source of vulnerabilities due to the complexities of parsing in unsafe memory languages such as C and C++. There does not appear to be any open source implementations of the CCSDS TCP/IP protocol stack.

Figure 1 – CCSDS Space communications protocols reference model

The CubeSat Protocol (CSP) is a free open source TCP/IP stack implementation for communication over space datalinks, similar to the CCSDS TCP/IP stack. The CSP protocol library is implemented in C, open source and implemented in many Cubesats that have been deployed to space. The protocol can be used for communication from ground station to satellite, inter-satellite and the intra-satellite communication bus. There have been 3 vulnerabilities to date reported in this protocol.

Figure 2 below shows what a Cubesat architecture looks like from a trust boundary perspective relative to the satellite and other satellites within the constellation and the earth.

Figure 2 – Space LEO Cubesat architecture trust boundaries

No hardware, software, operating system or protocol is completely free of vulnerabilities. What is important from a security perspective is:

1. The accessibility of the attack surface
2. The motives and capabilities of the adversary to exploit an exposed vulnerability if present in the attack surface

As these low-cost satellites get launched in our LEO and become more connected, any exposed technology stack will become increasingly targeted by cybercriminals.

Space 4.0 Threat Modeling

This Space 4.0 threat model focuses on the cybercriminal and how they can exploit Space 4.0 data for monetization. The following Space 4.0 factors will make it more accessible to cybercriminals:

1. Mass deployment of small satellites to LEO
2. Cheaper satellites with COTS components and increased satellite on board software processing (no longer relay devices)
3. Satellite service models, Ground Station-as-a-Service (GSaaS) and Satellite-as-a-Service (SataaS) and shared infrastructure across government, commercial and academic
4. Satellite connectivity and networks in space (ISL – inter-satellite links)
5. Space 4.0 data value

Space security has typically been analyzed from the perspective of ground segment, communications or datalink and space segment. Additionally, the attack classes have been categorized as electronic (jamming), eavesdropping, hijacking and control. Per figure 3 below, we need to think about Space 4.0 with a cybersecurity approach due to the increased connectivity and data, as opposed to the traditional approach of ground, communication and space segments. Cybercriminals will target the data and systems as opposed to the RF transmission layer.

Figure 3 – Space 4.0 threat modeling architecture

It is important to consider the whole interconnectivity of the Space 4.0 ecosystem as cybercriminals will exploit any means possible, whether that be direct or indirect access (another trusted component). Open source networked ground stations such as SatNOGs and the emerging NyanSat are great initiatives for space research but we should consider these in our overall threat model as they provide mass connectivity to the internet and space.

The traditional space security model has been built on a foundation of cost as a barrier to entry and perimeter-based security due to lack of physical access and limited remote access to satellites. However, once a device is connected to the internet the threat model changes and we need to think about a satellite as any other device which can be accessed either directly or indirectly over the internet.

In addition, if a device can be compromised in space remotely or through the supply chain, then that opens a new attack class of space to cloud/ground attacks.

Users and trusted insiders will always remain a big threat from a ground station perspective, just like enterprise security today, as they can potentially get direct access to the satellite control.

The movement of ground services to the cloud is a good business model if designed and implemented securely, however a compromise would impact many devices in space being controlled from the GSaaS. It is not quite clear where the shared responsibility starts and ends for the new SataaS and GSaaS Space 4.0 service models but the satellite key management system (KMS), data, GSaaS credentials and analytics intellectual property (this may reside in the user’s environment, the cloud or potentially the satellite but for the purposes of this threat model we assume the cloud) will be much valued assets and targeted.

From the Cyber and Space Threat Landscape review in part 1 <insert link>, combined with our understanding of the Space 4.0 architecture and attack surfaces, we can start to model the threats in Table 1 below.

Table 1 – Space 4.0 threats, attack classes and layers, and attack vectors

Based on the above threat model, let’s discuss a real credible threat and attack scenario. From our Space cyber threat landscape review in part 1 of this blog series, there were attacks on ground stations in 2008 at the Johnson Space Center and for a Nasa research satellite. In a Space 4.0 scenario, the cybercriminal attacks the ground station through phishing to get access to satellite communications (could also be a supply chain attack to get a known vulnerable satellite system into space). The cybercriminal uses an exploit being sold on the underground to exploit a remote wormable vulnerability within the space TCP/IP stack or operating system of the satellite in space, just like we saw EternalBlue being weaponized by WannaCry. Once the satellite has been compromised the malware can spread between satellite vendors using their ISL communication protocol to propagate throughout the constellation. Once the constellation has been compromised the satellite vendor can be held to ransom, causing major disruption to Space 4.0 data and/or critical infrastructure.

Moving Forward Securely for a Trustworthy Space 4.0 Ecosystem

Establishing a trustworthy Space 4.0 ecosystem is going to require strong collaboration between cyber threat research teams, government, commercial and academia in the following areas:

1. Governance and regulation of security standards implementation and certification/validation of satellite device security capabilities prior to launch
2. Modeling the evolving threat landscape against the Space 4.0 technology advancements
3. Secure reference architectures for end to end Space 4.0 ecosystem and data protection
4. Security analysis of the CCSDS protocols
5. Design of trustworthy platform primitives to thwart current and future threats must start with a security capable bill of materials (BOM) for both hardware and software starting with the processor then the operating system, frameworks, libraries and languages. Hardware enabled security to achieve confidentiality, integrity, availability and identity so that satellite devices may be resilient when under attack
6. Visibility, detection and response capabilities within each layer defined in our Space 4.0 architecture threat model above
7. Development of a MITRE ATT&CK specifically for Space 4.0 as we observe real world incidents so that it can be used to strengthen the overall defensive security architecture using TTPs and threat emulation

Space 4.0 is moving very fast with GSaaS, SataaS and talk of space data centers and high-speed laser ISL; security should not be an inhibitor for time to market but a contributor to ensure that we have a strong security foundation to innovate and build future technology on with respect to the evolving threat landscape. Space communication predates the Internet so we must make sure any legacy limitations which would restrict this secure foundation are addressed. As software complexity for on board processing and connectivity/routing capability increases by moving to the edge (space device) we will see vulnerabilities within the Space 4.0 TCP/IP stack implementation.

This is a pivotal time for the secure advancement of Space 4.0 and we must learn from the mistakes of the past with IoT where the rush to adopt new and faster technology resulted in large scale deployment of insecure hardware and software. It has taken much effort and collaboration between Microsoft and the security research community since Bill Gates announced the Trustworthy Computing initiative in 2002 to arrive at the state-of-the-art Windows 10 OS with hardware enabled security. Likewise, we have seen great advancements on the IoT side with ARM Platform Security Architecture and Azure Sphere. Many security working groups and bodies have evolved since 2002, such as the Trust Computing Group, Confidential Computing Consortium, Trusted Connectivity Alliance and Zero Trust concept to name a few. There are many trustworthy building block primitives today to help secure Space 4.0, but we must leverage at the concept phase of innovation and not once a device has been launched into space; the time is now to secure our next generation infrastructure and data source. Space security has not been a priority for governments to date but that seems all set to change with the “Memorandum on Space Policy Directive-5—Cybersecurity Principles for Space Systems”.

We should pause here for a moment and recognize the recent efforts from the cybersecurity community to secure space, such as the Orbital Security Alliance, S-ISAC, Mantech and Defcon Hack-a-Sat.

KubOS is being branded as the Android of space systems and we are likely to see a myriad of new software and hardware emerge for Space 4.0. We must work together to ensure Space 4.0 connectivity does not open our global connectivity and infrastructure dependency to the next Mirai botnet or WannaCry worm on LEO.

McAfee would like to thank Cork Institute of Technology (CIT) and its Blackrock Castle Observatory (BCO) and the National Space Center (NSC) in Cork, Ireland for their collaboration in our mission to secure Space 4.0.

The post Securing Space 4.0 – One Small Step or a Giant Leap? Part 2 appeared first on McAfee Blogs.

Our Experiences Participating in Microsoft’s Azure Sphere Bounty Program

From June to August, part of the McAfee Advanced Threat Research (ATR) team participated in Microsoft’s Azure Sphere Research Challenge.  Our research resulted in reporting multiple vulnerabilities classified by Microsoft as “important” or “critical” in the platform that, to date, have qualified for over $160,000 USD in bounty awards scheduled to be contributed to the ACLU ($100,000), St. Jude’s Children’s Research Hospital ($50,000) and PDX Hackerspace (approximately $20,000). With these contributions, we hope to support and give back both to our local hacker community that has really stepped up to help during the COVID crisis, and also recognize, at a larger scale, the importance to protect and further civil liberties and the wellbeing of those most in need.  

This blog post is a high–level overview of the program, why we choose to take part in it, and a brief description of our findings. A detailed technical walkthrough of our findings can be found here.  

Additionally, Microsoft has released two summary blogs detailing the Azure Sphere Bounty Program as a whole, including McAfee’s efforts and findings. They can be found here:

MSRC Blog

Azure Sphere Core Team Blog

What is Azure Sphere and the Azure Sphere Research Challenge? 

In late May Microsoft started a new bug bounty program for its Azure Sphere platform. Azure Sphere is a hardened IoT device with a secure communication link to the cloud that has been in development for the last few years and reached general availability in early 2020. Microsoft designed and built it from scratch to ensure every aspect of it is as secure as possible, per their security model. To put the theory to test, Microsoft invited a few select partners and hackers to try their best to defeat its security measures.  

The Azure sphere team came up with multiple scenarios that would test the security model of the device and qualify for an increased payout from the regular Azure Bug Bounty program. These scenarios range from the ability to bypass certain security measures, to executing code in the hardware enabled secure core of the device.  

Research scenarios specific to the Azure Sphere Research Challenge 

Why did ATR get involved with the program? 

There are multiple reasons why we were keen to participate in this program. First, as security researchers, the Azure Sphere platform is an exciting new research target that has been built from the ground up with security in mind. It showcases what might become of the IoT space in the next few years as legacy platforms are slowly phased out. Being at the forefront of what is being done in the IoT space ensures our research remains current and we are ready to tackle future new challenges. Second, by finding critical bugs in this new platform we help make it more secure and offer our support to make the IoT space increasingly resistant to cyber threats. Finally, as this is a bug bounty program, we decided from the start that we would donate any award we received to charity, thus using our skills to contribute to the social good of our local communities and support causes that transcend the technology sector.   

Findings 

We’ve reported multiple bugs to Microsoft as a result of our research that were rated Important or Critical: 

• Important – Security Feature bypass ($3,300): The inclusion of symlink in application package allows for referencing files outside of the application package mount point. 
• Critical – RCE ($48,000): The inclusion of a “character device” in an application package allows for direct interaction with a part of the flash memory, eventually leading to the modification of critical system files and further exploitation. 
• Important – EoP ($11,000): Multiple bugs in how uid_map files are processed, allowing for elevation of privilege to the sys user.  
• Important – Eop ($11,000): A user with sys privileges can trick Application Manager into unmounting “azcore” and mount a rogue binary in its stead. Triggering a core dump of a running process will then execute the rogue binary with full capabilities & root privileges due to improper handling of permissions in the LSM. 
• Critical – EoP ($48,000): Further problems in the privilege dropping of “azcore” leads to the complete bypass of Azure Sphere capability restrictions 
• Critical – EoP ($48,000): Due to improper certificate management, it is possible to re-claim a device on the Azure Sphere pre-prod server and obtain a valid capability file that works in the prod environment. This capability file can be used to re-enable application development mode on a finalized device (claimed by a third party). The deployment of the capability file requires physical access to a device.  

Conclusion 

This research was an exciting opportunity to look at a new platform with very little prior research, while still being in the familiar territory of an ARM device running a hardened Linux operating-system.  

Through the bugs we found we were able to get a full chain exploit from a locked device to having root access. However, the Azure Sphere platform has many more security features such as remote attestation, and a hardware enabled secure core that is still holding strong.  

Finally, we want to thank Microsoft for the opportunity of participating in this exciting program, and the bounty awards.  

The post Our Experiences Participating in Microsoft’s Azure Sphere Bounty Program appeared first on McAfee Blogs.

Celebrating multi-national cultures this Hispanic Heritage Month

Do you know the difference between Hispanic and Latino? What about the traditions that are important parts of the Hispanic culture? Or beloved Spanish or Portuguese phrases that don’t come across in English?

McAfee’s team spans 45 countries, making us a team rich in cultural diversity. We are always learning more about each other and celebrate Latin culture year-round. To commemorate Hispanic Heritage Month, which runs from September 15 – October 15, we’ve asked members of our McAfee Latino Community for their unique perspective on what being Latino means to them and to share more of the distinctive elements of their country of origin and traditions.

Check out some of the wonderful responses we received:

What Being Latino Means to Me:

We couldn’t be more proud to celebrate Hispanic Heritage Month by elevating the voices of our team members and celebrating the diverse backgrounds and cultures that make up McAfee.

Simply put, a welcoming work culture where every team member feels accepted and celebrated is part of our DNA. We value all voices which make up McAfee and appreciate how they further enrich our culture.

Interested in joining a company that supports inclusion and belonging? Search our jobs. Subscribe to job alerts. 

The post Celebrating multi-national cultures this Hispanic Heritage Month appeared first on McAfee Blogs.

CVE-2020-16898: “Bad Neighbor”

CVE-2020-16898: “Bad Neighbor”

CVSS Score: 8.8

Overview
Today, Microsoft announced a critical vulnerability in the Windows IPv6 stack, which allows an attacker to send maliciously crafted packets to potentially execute arbitrary code on a remote system. The proof-of-concept shared with MAPP (Microsoft Active Protection Program) members is both extremely simple and perfectly reliable. It results in an immediate BSOD (Blue Screen of Death), but more so, indicates the likelihood of exploitation for those who can manage to bypass Windows 10 and Windows Server 2019 mitigations. The effects of an exploit that would grant remote code execution would be widespread and highly impactful, as this type of bug could be made wormable. For ease of reference, we nicknamed the vulnerability “Bad Neighbor” because it is located within an ICMPv6 Neighbor Discovery “Protocol”, using the Router Advertisement type.

Vulnerability Details
A remote code execution vulnerability exists when the Windows TCP/IP stack improperly handles ICMPv6 Router Advertisement packets that use Option Type 25 (Recursive DNS Server Option) and a length field value that is even. In this Option, the length is counted in increments of 8 bytes, so an RDNSS option with a length of 3 should have a total length of 24 bytes. The option itself consists of five fields: Type, Length, Reserved, Lifetime, and Addresses of IPv6 Recursive DNS Servers. The first four fields always total 8 bytes, but the last field can contain a variable number of IPv6 addresses, which are 16 bytes each. As a result, the length field should always be an odd value of at least 3, per RFC 8106:

When an IPv6 host receives DNS options (i.e., RDNSS and DNSSL
options) through RA messages, it processes the options as follows:

   o  The validity of DNS options is checked with the Length field;
      that is, the value of the Length field in the RDNSS option is
      greater than or equal to the minimum value (3) and satisfies the
      requirement that (Length - 1) % 2 == 0.

When an even length value is provided, the Windows TCP/IP stack incorrectly advances the network buffer by an amount that is 8 bytes too few. This is because the stack internally counts in 16-byte increments, failing to account for the case where a non-RFC compliant length value is used. This mismatch results in the stack interpreting the last 8 bytes of the current option as the start of a second option, ultimately leading to a buffer overflow and potential RCE.

It is likely that a memory leak or information disclosure bug in the Windows kernel would be required in order to build a full exploit chain for this vulnerability. Despite this, we expect to see working exploits in the very near future.

Threat Surface
The largest impact here will be to consumers on Windows 10 machines, though with Windows Updates the threat surface is likely to be quickly minimized. While Shodan.io shouldn’t be counted on as a definitive source, our best queries put the number of Windows Server 2019 machines with IPv6 addresses is in the hundreds, not exceeding approximately 1000. This is likely because most servers are behind firewalls or hosted by Cloud Service Providers (CSPs) and not reachable directly via Shodan scans.

Detection
We believe this vulnerability can be detected with a simple heuristic that parses all incoming ICMPv6 traffic, looking for packets with an ICMPv6 Type field of 134 – indicating Router Advertisement – and an ICMPv6 Option field of 25 – indicating Recursive DNS Server (RDNSS). If this RDNSS option also has a length field value that is even, the heuristic would drop or flag the associated packet, as it is likely part of a “Bad Neighbor” exploit attempt.

Mitigation
Patching is always the first and most effective course of action. If this is not possible, the best mitigation is disabling IPv6, either on the NIC or at the perimeter of the network by dropping ICMPv6 traffic if it is non-essential. Additionally, ICMPv6 Router Advertisements can be blocked or dropped at the network perimeter. Windows Defender and Windows Firewall fail to block the proof-of-concept when enabled. It is unknown yet if this attack can succeed by tunneling the ICMPv6 traffic over IPv4 using technologies like 6to4 or Teredo. Our efforts to repeat the attack in this manner have not been successful to date.

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 this vulnerability, as well as a similar vulnerability (CVE-2020-16899). Unlike “Bad Neighbor”, the impact of CVE-2020-16899 is limited to denial-of-service in the form of BSoD.

NSP Attack ID: 0x40103a00 – ICMP: Windows IPv6 Stack Elevation of Privilege Vulnerability (CVE-2020-16898)
NSP Attack ID: 0x40103b00 – ICMP: Windows Function Discovery SSDP Provider Elevation of Privilege Vulnerability (CVE-2020-16899)

Additionally, we are releasing Suricata rules to detect potential exploitation of these vulnerabilities. Due to limitations in open source tools such as Snort and Suricata, we found that implementing the minimal detection logic described earlier required combining Suricata with its built-in Lua script parser. We have hosted the rules and Lua scripts at our public GitHub under CVE-2020-16898 and CVE-2020-16899 respectively. Although we have confirmed that the rules correctly detect use of the proof-of-concepts, they should be thoroughly vetted in your environment prior to deployment to avoid risk of any false positives.

The post CVE-2020-16898: “Bad Neighbor” appeared first on McAfee Blogs.

Spotlighting McAfee’s Women in Technology Scholarship Recipients

Working at McAfee is so much more than fighting off cyber-attacks; it’s also about learning valuable life lessons and fostering meaningful relationships. Recipients of our Women in Technology (WIT) Scholarship learned firsthand the immeasurable growth and invaluable experience gained at McAfee through their participation in the summer internship program in Cork, Ireland.

As we accept applications for prospective scholars from now until November 20, we are reminded of the positive impact this program has had on previous participants. The program offers 3000 Euro annum for the chosen student per year of the course, a summer internship at McAfee Cork, and a mentor who offers guidance to the scholar on managing their academic career.

From building professional relationships to developing the skills needed for a successful career in STEM-related fields through mentorships and training, four Women in Technology (WIT) Scholarship winners share their unique experiences in the program:

Alison, Mathematical Sciences

The WIT Scholarship has been incredible for me in so many ways—from the practical experience of working at McAfee to the inspiration and support that I have received from my mentors and other brilliant people during my time here. I was able to put the monetary support I received towards studying at UC San Diego in 2019. The scholarship has opened so many doors for me.

The skills I have learned at McAfee have helped me with my University projects. I had the chance to improve my coding abilities, learn new languages, and use statistical tools. In an educational environment, you sometimes miss the “Why are we doing this?” aspect of learning a new skill. Through my projects at McAfee, I understood the practical implementation of coding and statistics, which gave me a greater appreciation for what I was learning in school and motivated me to further improve my skills.

Clodagh, Financial Maths and Actuarial Science

During my internship, I had the chance to work with the Database Security team. I really felt like a member of the team and was made to feel valued. Everyone in McAfee was extremely friendly and approachable.

In addition to receiving the scholarship, I was lucky enough to receive two mentors. My initial mentor Ciara was incredibly thoughtful, motivational, and truly inspiring. She encouraged me to take part in extracurricular activities, so I became a committee member of the Math society in UCC. She provided me with numerous inspirational books and was always readily available to answer any questions. At the end of my second-year scholarship, I received a new mentor: Jill. She  was incredibly helpful, kind, and a valuable resource in my career progression.

My plan for the future is to learn more coding languages and hopefully complete another internship with McAfee! It is truly an amazing experience.

Jade, Mathematical Sciences

I had the opportunity to work alongside the Applied Data Science team. They gave me lots of advice and enlightened me on their own career journeys. Their experiences gave me confidence and reassurance in my course choice and I realized that there are so many career opportunities in programming. I’ve learned so many new skills, some of which were not covered in school, and I feel like I have a true advantage in the industry.

I have learned so much about working in a multinational company. I participated in the daily stand-ups with the team. I learned about sprint demos as well as the Agile and Waterfall methods. I attended all-hands meetings, which was a brand-new experience for me. I learned how to research effectively and swiftly pass that information onto my team. I also participated in an internal dataset competition; First, learning about Machine Learning and then building my own. I managed to host my own meeting for others who wanted to get involved, which was nerve-wracking but I’m glad I did it.

Aine, Data Science & Analytics

I’m incredibly grateful for the vast support and opportunities that I have received through my learning path in STEM to date, particularly my involvement in the McAfee WIT Scholarship Program. My experience with McAfee has  further enriched my educational experience and cultivated my passion for science and technology.  As a result of receiving this scholarship, I’ve developed a particular interest in the application of data science in cyber-security. Cyber crime and cyber threats have an ever-increasing potential to cause serious harm to our society so I’m fascinated by the application of data science, machine learning and artificial intelligence in saving lives.

Want to become a 2020 WIT Scholar? Apply now!

Know any future scientists? The closing date to apply for the WIT Scholarship is Friday, November 20, 2020. For more details on applying, click here.

The post Spotlighting McAfee’s Women in Technology Scholarship Recipients appeared first on McAfee Blogs.

Operation North Star: Behind The Scenes

Executive Summary

It is rare to be provided an inside view on how major cyber espionage campaigns are conducted within the digital realm. The only transparency afforded is a limited view of victims, a malware sample, and perhaps the IP addresses of historical command and control (C2) infrastructure.

The Operation North Star campaign we detailed earlier this year provided just this. This campaign used social media sites, spearphishing and weaponized documents to target employees working for organizations in the defense sector. This early analysis focused on the adversary’s initial intrusion vectors, described the first stages of how an implant was installed, and how it interacted with the Command and Control (C2) server.

However, that initial disclosure left gaps such as the existence of secondary payload, and additional insights into how the threat actors carried out their operations and who they targeted. The updated report takes a unique deep dive following our identification of previously undiscovered information into the backend infrastructure run by the adversaries.

These findings reveal a previously undiscovered secondary implant known as Torisma. However, more telling are the operational security measures that were undertaken to remain hidden on compromised systems. In particular, we saw the application of an Allow and Block list of victims to ensure the attacker’s secondary payload did not make its way to organizations that were not targeted. This tells us that certainly there has been a degree of technical innovation exhibited not only with the use of a template injection but also in the operations run by the adversary.

Finally, while we cannot confirm the extent of the success of the adversary’s attacks, our analysis of their C2 log files indicate that they launched attacks on IP-addresses belonging to internet service providers (ISPs) in Australia, Israel and Russia, and defense contractors based in Russia and India.

The findings within this report are intended to provide you, the reader, unique insights into the technology and tactics the adversary used to target and compromise systems across the globe.

Compromised Site

Operation North Star C2 infrastructure consisted of compromised domains in Italy and other countries. Compromised domains belonged, for example, to an apparel company, an auction house and printing company. These URLs hosted malicious DOTM files, including a malicious ASP page.

• hxxp://fabianiarte.com:443/uploads/docs/bae_defqa_logo.jpg
• hxxps://fabianiarte.com/uploads/imgproject/912EC803B2CE49E4A541068D495AB570.jpg
• https://www.fabianiarte.com/include/action/inc-controller-news.asp

The domain fabianiarte.com (fabianiarte.it) was compromised to host backend server code and malicious DOTM files. This domain hosted DOTM files that were used to mimic defense contractors’ job profiles as observed in Operation North Star, but the domain also included some rudimentary backend server code that we suspect was used by the implant. Log files and copies appeared in the wild pertaining to the intrusion of this domain and provided further insight. According to our analysis of this cache of data this site was compromised to host code on 7/9/2020.

Two DOTM files were discovered in this cache of logs and other intrusion data. These DOTM files belong to campaigns 510 and 511 based on the hard-coded value in the malicious VB scripts.

• 22it-34165.jpg
• 21it-23792.jpg

Developments in Anti-Analysis Techniques

During our analysis we uncovered two DOTM files as part of the cache of data pertaining to the backend. In analyzing first stage implants associated with the C2 server over a period of seven months, we found that there were further attempts by the adversary to obfuscate and confuse analysts.

Having appeared in July, these DOTM files contained first stage implants embedded in the same location as we documented in our initial research.  However, previous implants from other malicious DOTM files were double base64 encoded and the implants themselves were not further obfuscated. However, there were some notable changes in the method that differed from those detailed in our initial research:

• The first stage implant that is nested in the DOTM file, is using triple base64 encoding in the Visual Basic Macro
• The extracted DLL (desktop.dat) is packed with the Themida packer attempting to make analysis more difficult.

The first stage implant extracted from the DOTM files contains an encrypted configuration file and an intermediate dropper DLL. The configuration file, once decrypted, contains information for the first stage implant. The information includes the URL for the C2 and the decryption keys for the second stage payload called “Torisma”.

Contents of decrypted configuration

Because the configuration file contains information on how to communicate with the C2, it also stores the parameter options (ned, gl, hl). In this case, we see an unknown fourth parameter known as nl, however it does not appear to be implemented in the server-side ASP code. It is possible that the adversary may have intended to implement it in the future.

Appearance of nl parameter

In addition, analysis of the backend components for this compromised server enables us to draw a timeline of activity on how long the attacker had access. For example, the DOTM files mentioned above were placed on the compromised C2 server in July 2020. Some of the main malicious components involved in the backend operation were installed on this server in January 2020, indicating that this C2 server had been running for seven months.

Digging into the Heart of Operation North Star – Backend

Inc-Controller-News.ASP

As we covered in our initial Operation North Star research, the overall attack contained a first stage implant delivered by the DOTM files. That research found specific parameters used by the implant and that were sent to the C2 server.

Further analysis of the implant “wsdts.db” in our case, revealed that it gathers information of the victim’s system. For example:

• Get system disks information
• Get Free disk space information
• Get Computer name and (logged in) Username
• Process information

When this information is gathered, they will be communicated towards the C2 server using the parameters (ned, gl, hl).

These parameters are interpreted by an obfuscated server-side ASP page, based on the values sent will depend on the actions taken upon the victim. The server-side ASP page was placed on the compromised server January 2020.

Additionally, based on this information the adversary is targeting Windows servers running IIS to install C2 components.

The server-side ASP page contains a highly obfuscated VBScript embedded that, once decoded, reveals code designed to interact with the first stage implant. The ASP page is encoded with the VBScript.Encode method resulting in obfuscated VBScript code. The first stage implant interacts with the server-side ASP page through the usage of these finite parameters.

Encoded VBScript

Once the VBScript has been decoded it reveals a rather complex set of functions. These functions lead to installing additional stage implants on the victim’s system. These implants are known as Torisma and Doris, both of which are base64 encoded. They are loaded directly into memory via a binary stream once conditions have been satisfied based on the logic contained within the script.

Decoded VBScript

The ASP server-side script contains code to create a binary stream to where we suspect the Torisma implant is written. We also discovered that the Torisma implant is embedded in the ASP page and decoding the base64 blob reveals an AES encrypted payload. This ASP page contains evidence that indicates the existence of logic that decodes this implant and deliver it to the victim.

Depending on the values sent, additional actions are performed on the targeted victim. Further analysis of the server-side script indicates that there is logic that depends on some mechanism for the actor to place a victim’s IP address in an allowed-list file. The second stage implant is not delivered to a victim unless this condition is met first. This alludes to the possibility that the actor is reviewing data on the backend and selecting victims, this is likely performed through another ASP page discovered (template-letter.asp).

The server-side ASP page contains code to interpret the data sent via the following parameters to execute additional code. The values to these parameters are sent by the first stage implant initially delivered by the DOTM files. These parameters were covered in our initial research, however having access to the C2 backend code reveals additional information about their true purpose.

The URL query string is sent to the C2 server in the following format.

Further, code exists to get the infected victim’s IP address; this information is used to check if the IP address is allowed (get the second stage) or if the IP address has been blocked (prevent second stage). As mentioned previously, the addition of the victim’s IP address into the fake MP3 files is likely performed manually through identification of incoming connections through the stage 1 implant.

The full code of the logic gets the IP address for the connecting client machine and writing victim entries to a log file. In breaking down this code we can see different functionality is used that is most interesting. These log files are also stored within the WWW root of the compromised server based on the variable strlogpath.

From the below code-snippet of the vbscript, we can see that the “gl” and “hl” parameters are used to query the system information from the victim (gl) and the OS architecture (32 or 64 bits):

Victim Logging

The adversary keeps track of victims through logging functionality that is implemented into the server-side ASP code. Furthermore, as described above, the backend server code has the ability to perform victim logging based on first stage implant connections. This log file is stored in the WWW root directory on the compromised C2 server. The following code snippet will write data to a log file in the format [date, IP Address, User Agent, Campaign Code (NED), System Info (GL), OS Architecture (HL)].

The server-side ASP code will check whether the IP address is part of an allow-list or block-list by checking for the presence of the IP in two server-side files masquerading as MP3 files. The IP address is stored in the format of an MD5 hash, contained within the server-side code as a function to create a MD5 hash. The code is looking for these files in the WWW root of the compromised server based on the variable strWorkDir.

Using an ‘allow-list’ is a possible indication that it contained the list of their pre-determined targets.

IP allow-list / blocklist checking

For MD5 hash generation, the system appears to be using a non-standard form of hashing for the IP addresses. In most cases, the built in Microsoft cryptographic service provider would be used to generate an MD5. In this case, however, the actor chose to use a custom method instead.

The IP address is retrieved and hashed using this method.

The following function (ipopk) is set to read from a file that stores hashed IPs and will be used later in a conditional block statement. The code below will open and read a file, if there is no data the flag for ipok will result in 0, if there is data then the resulting value will be 1.

The following code is the logic to determine if an infected victim should receive the Torisma implant. A series of cases are used to make the decision depending on specific conditions as depicted in the code. Below the cases are explained:

• If the victim’s IP-address is on the allow-list, and the OS architecture bit value is “1” (resembling 64 bits), the Torisma 64 bits version implant will be sent to the victim and in the log file the term “case_1_64” is written behind the victim, meaning 64 bit version of the Torisma implant sent.
• Same for the second case but now for a 32-bit version OS (value 0) and the term “case_1_86” is written, meaning 32-bit implant version of torisma sent.
• If the ip-address of the victim is on the block list with either 32/64 bit OS architecture, a non-sense payload called “doris_x86” “doris_x64” will be sent to the victim. For example, in our case this was the value for “doris_x86”: DoriS_x86=”ddddddd”
• If condition “24” is returned from the victim, a log entry is written with value “case_3” and no implant sent and an http response status of 405 is sent
• If neither of the above conditions are met, “case_4” is written in the log-file, no implant sent and again an http response status of 405 is sent.

An http 405 response code indicates that the request method is known by the server but is not supported by the target resource.

Logic to deliver 2^nd stage implant to victim

Inside the Torisma Implant

One of the primary objectives of Operation North Star from what we can tell is to install the Torisma implant on the targeted victim’s system based on a set of logic. Further, the end goal is executing custom shellcode post Torisma infection, thus running custom actions depending on the specific victim profiles. As described earlier, Torisma is delivered based on data sent from the victim to the command and control server. This process relies on the first stage implant extracted from VB macro embedded in the DOTM file.

General process flow and component relationship

Further, Torisma is a previously unknown 2^nd stage implant embedded in the server-side ASP page as a base64 encoded blob. Embedded is a 64 and 32-bit version and depending on the OS architecture flag value sent by the victim and will determine what version is sent. Further this implant is loaded directly into memory as a result of interaction between the victim and the command and control server. The adversary went to great lengths to obfuscate, encrypt and pack the 1^st and 2^nd stage implants involved in this specific case.

Once Torisma is decoded from Base64 the implant is further encrypted using an AES key and compressed. The server-side ASP page does not contain any logic to decrypt the Torisma implant itself, rather it relies on decryption logic contained within the first stage implant. The decryption key exists in an encrypted configuration file, along with the URL for the command and control server.

This makes recovery of the implant more difficult if the compromised server code were to be recovered by incident responders.

The decryption method is performed by the first stage implant using the decryption key stored in the configuration file, this key is a static32-bit AES key. Torisma can be decoded with a decryption key 78b81b8215f40706527ca830c34b23f7.

Further, after decrypting the Torisma binary, it is found to also be packed with lz4 compression giving it another layer of protection. Once decompressing the code, we are now able to analyze Torisma and its capabilities giving further insight into Operation North Star and the 2^nd stage implant.

The variant of the implant we analyzed was created 7/2/2020; however, given that inc-controller-news.asp was placed on the C2 in early 2020, it indicates the possibility of multiple updates.

Based on the analysis, Torisma is sending and receiving information with the following URLs.

• hxxps://www.fabianiarte.com/newsletter/arte/view.asp
• hxxps://www.commodore.com.tr/mobiquo/appExtt/notdefteri/writenote.php
• hxxp://scimpex.com:443/admin/assets/backup/requisition/requisition.php

Encrypted Configuration File

Torisma also uses encrypted configuration files just as with the 1^st stage implant to indicate what URLs it communicates with as a command and control, etc.

Decrypted configuration file

The configuration file for Torisma is encrypted using the algorithm VEST[1] in addition to the communication sent over the C2 channel. From our research this encryption method is not commonly used anywhere, in fact it was a proposed cipher that did not become a standard to be implemented in general technologies[2].

Further, the FOUND002.CHK file recovered from the backend is used to update the configuration and contains just URLs with .php extension. These URLs have pages with a .php extension, indicating that some of the backend may have been written in PHP. It’s unclear what the role of the servers with .PHP pages have in the overall attack. Though we can confirm based on strings and functions in Torisma that there is code designed to send and receive files with the page view.asp. This view.asp page is the Torisma implant backend from what our analysis shows here. Later in this analysis we cover more on view.asp, however that page contained basic functionality to handle requests, send and receive data with an infected victim that has the Torisma implant.

Main Functionality

According to our analysis, the Torisma code is a custom developed implant focused on specialized monitoring.

The role of Torisma is to monitor for new drives added to the system as well as remote desktop connections. This appears to be a more specialized implant focused on active monitoring on a victim’s system and triggering the execution of payloads based on monitored events. The end objective of Torisma is executing shellcode on the victim’s system and sending the results back to the C2.

The Torisma code begins by running a monitoring loop for information gathering.

Information gathering loop

General Process

It runs the monitoring routine but will first check if monitoring is enabled based on the configuration (disabled by default). The general logic of this process is as follows:

1. If monitoring is disabled, just return
2. Else call the code that does the monitoring and upon completion temporarily disable monitoring
3. When run, the monitoring will be executed for a specified amount of time based on a configuration value
4. Upon return of the monitoring function, the code will proceed to command and control communication
5. If there is repeated failure in communication, the implant will force monitoring for 1hr and then retry the communication
6. Repeat forever

Triggering monitoring based on configuration

Monitoring

The monitoring loop will retrieve the address of WTSEnumerateSessionsW and the local mac address using GetAdaptersInfo.

1. The code will execute on a loop, until either enough time has elapsed (end time passed a parameter) or an event of interest occurred

Monitoring loop

2. It will monitor for an increase in the number of logical drives and Remote Desktop Sessions (RDS). If either occur, a status code will be set (5. New drive, 6. New RDS session) and the monitoring loop stops.

Drive tracking

a. It uses GetlogicalDrives to get a bitmask of all the drives available on the system, then iterates over each possible drive letter

b. It will also use GetDriveType to make sure the new drive is not a CD-ROM drive

Check drive type

3. It keeps track of the number of drives previously seen and will return 1 if the number has increased

RDP Session Tracking

The RDP session tracking function operates the same as the drive tracking. If the number increases by one it then returns 1. It uses WTSEnumerateSessionsW to get a list of sessions, iterates through them to count active ones.

Get active RDP sessions

Get active RDP sessions, continued

Command and Control Communication

The C2 code is interesting and is a custom implementation. The general process for this protocol is as follows.

1. Generates a connection ID that will be kept throughout this step as a hex string of five random bytes for each module (0x63) and random seeded with the output of GetTickCount64

Generate connection ID

2. Next it loads a destination URL
   a. There are three available servers hardcoded in the implant as an encrypted blob
   2. b. The decryption is done using a VEST-32 encryption algorithm with the hardcoded key ff7172d9c888b7a88a7d77372112d772

Configuration Decryption

c. A random configuration number is picked (mod 6) to select this configuration

d. There are only 3 configurations available, if the configuration number picked is above 3, it will keep incrementing (mod 6) until one is picked. Configuration 0 is more likely to be chosen because of this process.

Code to pick configurations

3. It will send a POST request to the URL it retrieved from the configuration with a “VIEW” action. It builds a request using the following hardcoded format string.

a. The process will be looking for the return of the string Your request has been accepted. ClientID: {f9102bc8a7d81ef01ba} to indicate success

4. If successful, it will retrieve data from the C2 via a POST request, this time it will use the PREVPAGE action

a. It uses the following format string for the POST request

b. The reply received from the server is encrypted it. To decrypt it the following process is needed

i. Replace space with +

ii. Base64 decode the result

iii. Decrypt the data with key “ff7172d9c888b7a88a7d77372112d772”

Server decryption using key

iv. Perform a XOR on the data

Perform XOR on the data

7. 7. The decrypted data is going to be used to execute a shellcode from the server and send data back

a. Data from the server will be split into a payload to execute and the data passed as an argument that is being passed to it
b. Part of the data blob sent from the server is used to update the local configuration used for monitoring

i. The first 8 bytes are fed to a add+xor loop to generate a transformed version that s compared to hardcoded values

Configuration check

Configuration check continued

ii. If the transformed data matched either of the two hardcoded values, the local configuration is updated

iii. In addition, the duration of the observation (for the Drive/RDS) loop can be updated by the server

iv. If the duration is above 0x7620 (21 days) it will then re-enable the monitoring even if the configuration detailed above had disabled it

v. If the transformed data doesn’t match any of the two hardcoded values, then monitoring will be disabled by the configuration

c. The implant will create a new communication thread and will wait until its notified to continue. It will then proceed to execute the shellcode and then wait for the other thread to terminate.

d. Depending on what occurred (an error occurred, or monitoring is enabled/disabled) the code will return a magic value that will decide if the code needs to run again or return to the monitoring process.

Return to communications loop

8. 8. The communications thread will create a new named pipe (intended to communicate with the shellcode). It the notifies the other thread once the pipe is ready and then proceed to send data read from the pipe to the server.

a. The pipe name is \\.\pipe\fb4d1181bb09b484d058768598b

Code for named pipe

b. It will read data from the pipe (and flag the processing as completed if it finds “- – – – – – – – -“

c. It will then send the data read back to the C2 by sending a POST in the following format

d. Data is encrypted following the same pattern as before, data is first XORED and then encrypted using VEST-32 with the same key as before

e. This will be repeated until the payload thread sends the “- – – – – – – – -“message or that the post failed

Campaign Identification

One way the adversary keeps track of what victims are infected by what version of the first stage implant is by using campaign IDs. These IDs are hard coded into the VB macro of the template document files that are retrieved by the first stage maldoc.

They are sent to the backend server through the NED parameter as covered earlier, further they are read and interpreted by the ASP code.

Victimology

According to the raw access logs for Inc-Controller-News.asp it is possible to understand what countries were impacted and it matches with the logs we discovered along another .asp page (view.asp), which we will explain later in the document.

Based on one of C2 log files we could identify the following about the victims:

• Russian defense contractor
• Two IP addresses in two Israeli ISP address spaces
• IP addresses in Australian ISP space
• IP address in Russian ISP address space
• India-based defense contractor

Template-letter.asp

During our investigation we uncovered additional information that led to the discovery of additional ASP pages. One ASP page discovered on the same compromised command and control server contained interesting code. First this ASP page is encoded in the same method using VB.Encode as we observed with the code that delivers the Torisma implant. Second it appears that the code is part of the core backend managed by the attacker and had the original file name of board_list.asp. Based on in the wild submission data the file board_list.asp first appeared in Korea October 2017, this suggests that this code for this webshell has been in use since 2017.

Further, this ASP page is a custom webshell that according to our knowledge and sources is not an off-the-shelf common webshell, rather something specifically used in these attacks. Some of the actions include browsing files, executing commands, connecting to a database, etc. The attacker is presented with the login page and a default base64 encoded password of ‘venus’ can be used to login (this value is hardcoded in the source of this page).

Template-Letter.ASP main page

Functionality to execute commands

 VIEW.ASP -Torisma Backend

The View.ASP file is equally important as the inc-controller-news.asp file and contains interesting functionality. This ASP page is the backend code for the Torisma implant, and the functions are intended to interact with the infected victim.

The view.asp file contains the following references in the code:

The file “FOUND001.CHK” contains a “logfile” as the CONST value name possibly refers to “logvault”.

Analyzing the possible victims revealed an interesting list:

• Russia-based defense contractor
• Two IP addresses in two Israeli ISP address spaces
• IP address in Russian ISP address space
• India-based defense contractor

The file “FOUND002.CHK” contains a Base64 string that decodes to:

hxxps://www.krnetworkcloud.org/blog/js/view.php|www.krnetworkcloud.org|2|/blog/js/view.php|NT

The above domain was likely compromised to host malicious code, given it belongs to an Indian IT training company.

The Const value name for “FOUND002.CHK” is “cfgvault”, the first three letters might refer to “configuration”. This ASP code contains additional functions that may indicate what role this page has in the overall scheme of things. View.asp is the Torisma implant backend code with numerous functions implemented to handle requests from the implant as described earlier in this analysis. Based on our analysis of both the Torisma implant and this backend code, some interesting insight has been discovered.  First implemented in the ASP code are the general actions that can be taken by this backend depending on the interaction with Torisma.

Some of these actions are triggered by the implant connecting and the others may be invoked by another process. The main ASP page is implemented to handle incoming requests based on a request ACTION with several possible options to call. Given that the implant is driven by the “ACTION” method when it comes to the C2 communication, a number of these cases could be selected. However, we only see code implemented in Torisma to call and handle the request/response mechanism for NEXTPAGE and PREVPAGE, thus these other actions are likely performed by the adversary through some other process.

General actions by View.ASP

ViewPrevPage

As described in the analysis, the ViewPrevPage action is a function designed to handle incoming requests from Torisma to get data. The data sent to Torisma appears to be in the form of ~dmf files. This content for the ViewPrevPage action comes in the form of shellcode intended to be executed on the victim side according to the analysis of the implant itself.

ViewPrevPage function

ViewNextPage

Torisma uses this method to send data back to the C2 server read from the named pipe. This is the results of the execution of the shellcode on the victim’s system through the ViewPrevPage action and the results of this execution are sent and processed using this function.

Implant sends data to C2

ViewGallery

There is no function in Torisma implemented to call this function directly, this is likely called from another administration tool, probably implemented in the upstream server. A static analysis of this method reveals that it is likely intended to retrieve log files in a base64 encoded format and write the response. Like the Torisma implant, there is a response string that is received by the calling component that indicates the log file had been retrieved successfully and that it should then delete the log file.

Retrieve and write log file content in base64 format (ViewGallery)

ViewMons

Another function also not used by Torisma is intended to set the local configuration file. It appears to use a different request method than ACTION; in this case it uses MAILTO. Based on insight gathered from Torisma, we can speculate this is related to configuration files that are used by the implant.

ViewMons function

SendData

This function is used in the RedirectToAdmin method exclusively and is the mechanism for sending data to the upstream C2. It depends on the GetConfig function that is based on the stored value in the cfgvault variable.

Send Data

RedirectToAdmin

This function is used to redirect information from an infected victim to the master server upstream. This is an interesting function indicating additional infrastructure beyond the immediate C2 with which we observed Torisma communicating.

RedirectToAdmin

WriteAgentLog

As part of the process of tracking victim’s with Torisma, the ASP code has a function to write log files. These resulting log files indicate success for the execution of shellcode on victims running Torisma. This logging method captures the user agent and IP address associated with the victim being monitored. This function is called when the information is sent to the master server via the RedirectToAdmin method.

Analysis of the server logs indicates the following countries made connections to the View.ASP page in July 2020.

• India
• Australia
• Israel
• Finland

Webshells

During our analysis we were able to determine that in some instances the attacker used webshells to maintain access. Discovered on another compromised server by the same actor with the same type of code was a PHP Webshell known as Viper 1337 Uploader. Based on our analysis this is a modified variant of Viper 1337 Uploader.

Some additional log file analysis reveals that a dotm file hosted with a. jpg extension was accessed by an Israeli IP address. This IP address likely belongs to a victim in Israel that executed the main DOCX. Based on the analysis of the user-agent string belonging to the Israel IP address Microsoft+Office+Existence+Discovery indicates that the dotm file in question was downloaded from within Microsoft Office (template injection).

Attacker Source

According to our analysis the attacker accessed and posted a malicious ASP script “template-letter.asp” from the IP address 104.194.220.87 on 7/9/2020.  Further research indicates that the attacker is originating from a service known as VPN Consumer in New York, NY.

Snipped from log file showing attacker IP 104.194.220.87

From the same logfiles, we observed the following User Agent String:

“Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+Win64;+x64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+ms-office;+MSOffice+16)”

Decoding the User Agent string we can make the following statement

The attacker is using a 64bit Windows 10 platform and Office 2016.

The Office version is the same as we observed in the creation of the Word-documents as described in our document analysis part of Operation NorthStar.

Conclusion

It is not very often that we have a chance of getting the C2 server code pages and associated logging in our possession for analysis. Where we started with our initial analysis of the first stage payloads, layer after layer we were able to decode and reveal, resulting in unique insights into this campaign.

Analysis of logfiles uncovered potential targets of which we were unaware following our first analysis of Operation North Star, including internet service providers and defense contractors based in Russia and India.

Our analysis reveals a previously unknown second stage implant known as Torisma which executes a custom shellcode, depending on specific victim profiles, to run custom actions. It also illustrates how the adversary used compromised domains in Italy and elsewhere, belonging to random organizations such as an auction house and printing company, to collect data on victim organizations in multiple countries during an operation that lasted nearly a year.

This campaign was interesting in that there was a particular list of targets of interest, and that list was verified before the decision was made to send a second implant, either 32 or 64 bits, for further and in-depth monitoring. Progress of the implants sent by the C2 was monitored and written in a log file that gave the adversary an overview of which victims were successfully infiltrated and could be monitored further.

Our findings ultimately provide a unique view into not only how the adversary executes his attacks but also how he evaluates and chooses to further exploit his victims.

Read our McAfee Defender’s blog to learn more about how you can build an adaptable security architecture against the Operation North Star campaign.

Special thanks to Philippe Laulheret for his assistance in analysis

[1] https://www.ecrypt.eu.org/stream/p2ciphers/vest/vest_p2.pdf

[2] https://www.ecrypt.eu.org/stream/vestp2.html

The post Operation North Star: Behind The Scenes appeared first on McAfee Blogs.

Operation North Star: Summary Of Our Latest Analysis

McAfee’s Advanced Threat Research (ATR) today released research that uncovers previously undiscovered information on how Operation North Star evaluated its prospective victims and launched attacks on organizations in Australia, India, Israel and Russia, including defense contractors based in India and Russia.

McAfee’s initial research into Operation North Star revealed a campaign that used social media sites, spearphishing and weaponized documents to target employees working for organizations in the defense sector. This early analysis focused on the adversary’s initial intrusion vectors, the first stages of how an implant was installed, and how it interacted with the Command and Control (C2) server.

By deepening its investigation into the inner workings of North Star’s C2, McAfee ATR can now provide a unique view into not only the technology and tactics the adversary used to stealthily execute his attacks but also the kinds of victims he targeted.

The latest research probed into the campaign’s backend infrastructure to establish greater perspective into how the adversary targeted and assessed his victims for continued exploitation, and how he used a previously unknown implant called Torisma to execute this exploitation.

McAfee’s findings ultimately provide a unique view into a persistent cyber espionage campaign targeting high value individuals in possession of high value defense sector intellectual property and other confidential information.

VECTORS & INFRASTRUCTURE

Most analysis of cyber campaigns is typically reliant upon the dissection of malware and the telemetry of cyber defenses that have come into contact with those campaigns. McAfee’s analysis of Operation North Star complemented these elements by dissecting the C2 infrastructure that operated the campaign. In doing so, we gained a holistic view of its operations that is rarely available to threat researchers.

Attackers often send out many spearphishing emails to many potential targets rather than precisely targeting the highest value individuals. Once the victim opens a message and infects himself, the malware will try to fully exploit his system. But this broad, less precise approach of infecting many is “noisy” in that it is likely to be identified if these infections are happening at scale across an organization (let alone around the world).  Cyber defenses will eventually be able to recognize and stop it.

In the case of Operation North Star, the attackers researched their specific target victims, developed customized content to lure them, engaged them directly via LinkedIn mail conversations, and sent them sophisticated attachments that infected them in a novel way using a template injection tactic.

The campaign used legitimate job recruitment content from popular U.S. defense contractor websites to lure specific victims into opening malicious spear phishing email attachments. Notably, the attackers compromised and used legitimate web domains hosted in the U.S. and Italy to host their command and control capabilities. These otherwise benign domains belonged to organizations in a wide variety of fields, from an apparel manufacturer, to an auction house, to a printing company, to an IT training firm.

Using these domains to conduct C2 operations likely allowed them to bypass some organizations’ security measures because most organizations do not block trusted websites.

The first stage implant was delivered by DOTM files which, once established on a victim’s system, gathered information on that system such as disk information, free disk space information, computer name and logged in username and process information. It would then use a set of logic to evaluate the victim system data sent back by this initial implant to determine whether to install a second-stage implant called Torisma. All the while, it operated to achieve its objectives while minimizing the risk of detection and discovery.

General process flow and component relationship

Torisma is a previously undiscovered, custom-developed, second-stage implant focused on specialized monitoring of high value victims’ systems. Once installed, it would execute custom shellcode and run a custom set of actions depending on the victim systems’ profiles. The actions included active monitoring of the systems and execution of payloads based on observed events. For instance, it would monitor for an increase in the number of logical drives and Remote Desktop Sessions (RDS).

What is clear is that the campaign’s objective was to establish a long-term, persistent espionage campaign focused on specific individuals in possession of strategically valuable technology from key countries around the world.

VICTIMS & IMPACT

McAfee’s early analysis of Operation North Star’s spearphishing messages were written in Korean and exhibited mentions of topics specific to South Korean politics and diplomacy. But our latest analysis of North Star’s C2 log files enabled us to identify targets beyond South Korea:

• Two IP addresses in two Israeli ISP address spaces
• IP addresses in Australian ISP space
• IP address in Russian ISP address space
• India-based defense contractor
• Russian defense contractor

The campaign’s technologies and tactics—the installation of data gathering and system monitoring implants—suggests that the adversary is in a position to remain persistent, conduct surveillance on and exfiltrate sensitive data from its defense sector victims.

The detailed job descriptions used to lure victims and the selective use of the Torisma implant suggest that the attackers were pursuing very specific intellectual property and other confidential information from very specific defense technology providers. Less valuable victims were sidelined to be monitored silently over an extended period of time until they become more valuable.

VILLAINS & IMPLICATIONS

McAfee cannot independently attribute Operation North Star to a particular hacking group. McAfee has established that the code used in the spearphishing attachments is almost identical to that used by a 2019 Hidden Cobra campaign targeting Indian defense and aerospace companies. This could indicate that either Hidden Cobra is behind Operation North Star or another group is copying the group’s known and established technology and tactics. But sound, accurate attribution requires that technical analysis of such attacks be complemented by information from traditional intelligence sources available only to government agencies.

McAfee’s findings do suggest that the actors behind the campaign were more sophisticated than they initially appeared in our early analysis. They were focused and deliberate in what they meant to achieve and more disciplined and patient in their execution to avoid detection.

Please see our full report entitled “Operation North Star: Behind the Scenes” for a detailed review of ATR’s analysis of the campaign.

Also, please read our McAfee Defender’s blog to learn more about how you can build an adaptable security architecture against the Operation North Star campaign and others like it.

The post Operation North Star: Summary Of Our Latest Analysis appeared first on McAfee Blogs.

McAfee Labs Report Reveals Continuing Surge of COVID-19 Threats and Malware

The McAfee Advanced Threat Research team today published the McAfee Labs Threats Report: November 2020.

In this edition, we follow our preceding McAfee Labs COVID-19 Threats Report with more research and data designed to help you better protect your enterprise’s productivity and viability during challenging times.

What a year so far! The first quarter of 2020 included a rush of malicious actors leveraging COVID-19, and the trend only increased in the second quarter. For example, McAfee’s global network of more than a billion sensors registered a 605% increase in total Q2 COVID-19-themed threat detections. It’s an example of updated pandemic-related threats you can track on our McAfee COVID-19 Threats Dashboard.

This edition of our threat report also looks at other notable Q2 20 malware increases including:

• Attacks on cloud services users reached nearly 7.5 million
• New malware samples grew 11.5%, averaging 419 new threats per minute
• PowerShell malware surged 117%

To help ensure your data and systems remain secure, we have also made available the MVISION Insights preview dashboard to demonstrate the prevalence of such current campaigns. This dashboard also provides access to the Yara rules, IoCs, and mapping of such campaigns against the MITRE ATT&CK Framework. We update these campaigns on a weekly basis so, in essence, this threat report has an accompanying dashboard with more detail on specific campaigns.

I certainly hope that you see the value not only in the data presented within the threats report, but also with the dashboards. Your feedback is important to us.

Stay safe.

McAfee Labs Quarterly Threat Report – November 2020

What a year so far! We exited the first quarter of 2020 battling the rush of malicious actors leveraging COVID-19, and in the second quarter there are no signs that these attacks seem to be abating.

Download Now

The post McAfee Labs Report Reveals Continuing Surge of COVID-19 Threats and Malware appeared first on McAfee Blogs.

One Team Member Selflessly Provides Relief to COVID-19’s Front Line

By: Heiko, Senior Security Engineer, Germany

I never could have imagined that what started as a national duty to volunteer in Germany would spark an innate passion of giving back to those in need during a time of crisis.

For many years, German men were required to spend 15 months in the military after graduating from school or volunteer for community service for an equal amount of time over eight years. I chose to volunteer for the Technische Hilfswerk (THW). THW is a civic organization that provides professional help to people in distress.

Little did I know that the experience would be so rewarding that 23 years later, and with the help of McAfee’s Volunteer Time Off (VTO) benefit, I would be spending much of my free time helping those in need of THW’s services.

Providing a backup plan in the fight against the coronavirus

THW has been instrumental in providing much needed resources during the 2020 coronavirus pandemic, including erecting mobile clinical testing stations across the country and providing critical relief services for front line defense against the virus.

When the hot phase of COVID-19 reached Germany this spring, THW began preparing to build temporary hospital facilities in case the virus threatened to overwhelm hospitals. Temporary camps are built from scratch to house relief units of 500 people and more.

With more than two decades of disaster-response exercises and training behind me, I’ve become very acquainted with constructing these facilities. So, I wasn’t surprised when THW asked me to work with a local fire department to build one to increase the community’s hospital capacity for treating infected patients.

We organized containers with showers and toilets, designed the infrastructure to connect them to the existing water supply, arranged for beds and mattresses and planned needed power requirements. Volunteers assisted in transporting materials and supplies to the facility and assembling the various hospital pieces.

Developing a passion for assisting others

Over the years, volunteering for the THW has become a passion. Many of my best friends are part of the effort, which makes it even more rewarding.

Building the temporary camp was hard and required patience. For two weeks, the 12-hour days were taxing but it was worth it to contribute to the battle against COVID-19.

The spirit of our small group and others kept each of us motivated to meet our goal. Everyone did what he or she could do best, and people from other departments and organizations were willing to be as flexible as possible. I was proud to offer my training at THW to help pull together the community.

Regardless, it wouldn’t have been possible for me to help if not for McAfee’s support. My colleagues and manager chipped in to manage my projects, invoking the true spirit of teamwork.

There is no question that McAfee enables its employees to become a greater part of the community and assist whenever and wherever needed. That benefit makes it even more rewarding to give back to the community.

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.

The post One Team Member Selflessly Provides Relief to COVID-19’s Front Line appeared first on McAfee Blogs.

Honoring Our Brave Military Veterans from the McAfee Community

Paying Tribute

November 11 marks Veterans Day and Remembrance Day. It is a time for us to come together and honor the brave men and women who have risked their lives to protect our nations.

We pay tribute to those who have served in the U.S. military during Veterans Day. In the Commonwealth countries, we honor military members through Remembrance Day, a day to remember those who have passed on in the line of duty.

At McAfee, we’re proud to work with our veterans! They’ve served and protected our countries and today, they protect all that matters at McAfee.

To honor their sacrifice, we asked McAfee veterans to share throwback photos from their days of service or photos with loved ones in service. Check them out!

Thoughts from our veteran community
This Veterans Day, members from our McAfee Veterans Community share what this day means to them:

“This day reminds me of the people I worked with and the difference we made. It’s the people who volunteer to serve in the military, sacrificing years of their lives, and in some cases, their very lives, who guard and protect the freedoms guaranteed by the Constitution. All military personnel take an oath that, in part, says, ‘I will support and defend the Constitution of the United States against all enemies, foreign and domestic; that I will bear true faith and allegiance to the same.’ This oath doesn’t expire when a service member leaves military service.“

– Andrew, Senior Service Reliability Engineer, Cloud

“This day is the day we honor the silver haired guy in a Prius with a Silver Star license plate or the quiet thirty something mom in the store with her noisy kids wearing the Marine-Corps T-shirt with two tours in Afghanistan under her belt.. Not everyone was a Delta operative or a Navy SEAL. They all however – to a man and woman – had their place in the system that kept us safe. Find them; thank them for their service and your freedom.” 

–  Kevin, Customer Success Manager, CSG

“I will never stop being Ex Armed Forces. I think fondly of my time in the Royal Navy. I would do it all again in a heartbeat. I still get a lump in my throat when I hear “Heart of Oak” or the “The Last Post” being played. The friends I made and the people I met during my service from all countries and all parts of the Armed Forces, friend or foe, all have a similar vein running through them. Remembrance Day reminds me that while some of us are not here anymore, that vein is still with us and them.“

– Paul, Associate Technical Support Engineer, Customer Success Group

“My family has a history of service and I grew up knowing I would join the Military. I joined the Royal Navy in 1982 at age 18. I’m proud to have served and I will continue to observe the 1 minute silence and attend the remembrance service and take the time to remember the sacrifice. Lest we not forget. For those brave who gave their lives so we could live ours.” 

– Tudor,  Sr. Project Manager – New Product Information, Global Product Operations

We continue to make strides in actively recruiting veterans and nurturing career growth by empowering the transferable skills from active duty. Join us!

The post Honoring Our Brave Military Veterans from the McAfee Community appeared first on McAfee Blogs.

CVE-2020-17051: Remote kernel heap overflow in NFSv3 Windows Server

CVSS Score: 9.8 

Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C 

Overview 

Microsoft released a patch today for a critical vulnerability (CVE-2020-17051) in the Windows NFSv3 (Network File System) server. NFS is typically used in heterogenous environments of Windows and Unix/Linux for file sharing. The vulnerability can be reproduced to cause an immediate BSOD (Blue Screen of Death) within the nfssvr.sys driver. Interestingly, the November patches from Microsoft also include a remote kernel data read vulnerability in the same nfssvr.sys driver (CVE-2020-17056), which leads to a potential ASLR (address space layout randomization) bypass. The combination of these two vulnerabilities dramatically increases the likelihood of a remote exploit when used on Windows Server to bypass exploit mitigations.  CVE-2020-17051 is the first known vulnerability which has been disclosed within the Windows implementation of the NFSv3 protocol to the best of our knowledge.  

Threat Surface 

The vulnerability is believed to impact all versions of Windows Server when: 

1. An authenticated user has write access to any NFS share. 
2. An NFS share has been configured with anonymous write access (no authentication required) 

A Shodan query reported 38,893 servers with port 2049 exposed to the internet; however, it is unknown what percentage of these servers are actually NFS shares and actually configured with anonymous write access. The network share discovery technique is typically used by an adversary within the discovery phase of the MITRE ATT&CK framework with the objective to gain further privileges. CVE-2020-17051 would give adversaries the ability to spread worm–like within heterogenous Windows and Unix/Linux environments using anonymous write access file shares over NFSv3. 

Mitigation 

Patching is always the first and most effective course of action. If it’s not possible to patch, the best mitigation is to limit Windows NFSv3 server share write access internally and block any external access to vulnerable servers. 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 this vulnerability. 

NSP Attack ID: 0x40c01200 – NFS Microsoft Windows Network File System Remote Code Execution Vulnerability (CVE-2020-17051) 

The post CVE-2020-17051: Remote kernel heap overflow in NFSv3 Windows Server appeared first on McAfee Blogs.

McAfee Team Members Share Their Virtual Onboarding Experiences

At McAfee, ensuring our new team members are well prepared and supported for their roles is a top priority. From the first day of onboarding, team members are nurtured and given the tools they need for successful development.

McAfee’s traditional in-person orientation process has evolved virtually because of the pandemic. But the approach and goal is the same – to transition new team members as efficiently and comfortably as possible so they can make an immediate impact.

We asked four recent additions to the McAfee family what it’s like to join the company via virtual onboarding. They were asked to share how McAfee helped them acclimate to work life as a new employee and to offer highlights now that they’ve settled into their new roles.

Here is what they had to say:

Daniella, Regional Account Manager, Plano, Texas

Virtual resources make a difference: “It was my first time onboarding virtually and it felt like a once-in-a-lifetime experience. The process was executed very well, and all training materials were made available to me online. I believe providing these virtual resources was extremely helpful in my onboarding experience.”

Settling in with the right tools, team support: “Like most people in similar circumstances, I wondered what virtual onboarding was going to be like. How could I possibly retain this amount of information? At the end of the day, you realize that you really do have all the right resources. My manager was great and looped me in, and was able to help me to quickly acclimate to my role on the team. My onboarding buddy and fellow team members were also a huge help.”

Engaging and exceeding expectations: “I adapted to my new work life and virtually accomplished everything that most do in-person. I took all of my assessments online and team members offered the different resources that were essential to accomplishing my day-to-day work. My trainer was also very engaging throughout the process.”

Virtually learning to engage customers: “Through daily meetings, my sales coach prepared me for interactions with customers. I learned different ways to engage for meetings and customer visits, and was able to practice my sales pitch just as if it were in person.”

Building better relationships: “In cybersecurity, you are constantly in a state of learning. You never stop the process of improving yourself, your skills, your salesmanship and your relationships. I am now acclimated to my role and building better relationships with my customers.”

John, Global Business Director – Amazon, Seattle, Washington

A Productive Day One: “The basic onboarding process was easy and enabled me to get the necessary tools like a badge, email and computer equipment prior so that the first day on the job was more productive than prior experiences. I could preview the excellent benefits and enroll shortly after starting, as well as acquire office equipment necessary for me to work from home.”

Easy-to-follow training, introductions: “As an experienced leader, I had no apprehension about virtual onboarding. McAfee’s training and general onboarding introductions were easy to follow and required no advance preparation. While some of the training was time consuming, it was not a burden and frankly insightful.”

Finding balance and having fun: “My role is global, so I found balance between work and family time by juggling the global time zones and meetings. The numerous social and professional groups as well as the MS Teams program with McAfee helped with acclimating to the company. McAfee always keeps it fun with competitions and challenges on the Social Hub between employees. Virtual coffee and happy hours help too.”

Collaborative and better together: “We’re having a strong year, and a big reason is that the team has been very welcoming and always willing to provide training and support – very collaborative. Our best days lie ahead. We are better together and getting better every day.”

Mark, Director of Credit and Collections, Plano, Texas

A very normal virtual experience: “Initially, I experienced some apprehension about onboarding remotely. It’s difficult enough to learn a new job in the office, and I was worried that learning remotely without having someone sitting next to me might complicate training. But my anxiety quickly dissipated, and I can honestly say that the McAfee onboarding experience felt very normal. My manager, peers and those reporting to me were extremely helpful and stayed in constant communication as I navigated through the first several weeks at McAfee.”

Ease of learning through technology: “Virtual meetings via Teams helped me to quickly acclimate. Talking to others via video was comforting and enabled me to get to know other McAfee team members. McAfee’s onboarding technology made it very easy to learn remotely.”

No need to fear onboarding remotely: “I can truly say that the one major highlight that stands out for me is just getting to know so many amazing employees in this organization. No one should fear or have any anxiety when onboarding virtually at McAfee. It has been and continues to be a great and exciting experience!”

Rachel, Sr. Sales Operations Analyst, Plano, Texas

Easy to learn and understand: “The virtual onboarding experience was easy. The learning hub is an excellent resource and helped simplify the process, in addition to offering great product training. As someone who is not only new to McAfee but also the cybersecurity industry, I knew I would have a lot to catch up on. Everything was very easy to understand.”

Very responsive and helpful: “My recruiter stayed in touch with me and made sure my questions were answered. Any time I needed something, the human resources department was very responsive and helpful. My team also rallied around me and have provided a lot of support since I joined McAfee.”

Achieving a steady course: “I love it at McAfee and everyone has been so supportive. Teammates have been incredibly helpful in guiding me through each of their best practices so I could build my roadmap to success.”

Are you thinking about joining our team? McAfee takes great pride in providing a virtual onboarding experience with the right tools and support. Learn more about our jobs. Subscribe to job alerts.

The post McAfee Team Members Share Their Virtual Onboarding Experiences appeared first on McAfee Blogs.

SUNBURST Malware and SolarWinds Supply Chain Compromise

Part I of II

Situation

In a blog post released 13 Dec 2020, FireEye disclosed that threat actors compromised SolarWinds’s Orion IT monitoring and management software with a trojanized version of SolarWinds.Orion.Core.BusinessLayer.dll. The trojanized file delivers the SUNBURST malware through a backdoor as part of a digitally-signed Windows Installer Patch. Use of a Compromised Software Supply Chain (T1195.002) as an Initial Access technique is particularly critical as it can go undetected for a long period. FireEye released countermeasures that can identify the SUNBURST malware.

If you are using SolarWinds software, please refer to the company’s guidance here to check for vulnerable versions and patch information. McAfee has evaluated the published countermeasures and will continue to analyze further attack indicators. It’s important to note that this was a very sophisticated attack and customers are advised to assess their overall security architecture capability to either prevent, detect or respond to an APT threat. This attack reminds us that in today’s digital enterprise the supply chain includes many diverse elements including but not limited to critical equipment and hardware, cloud software and infrastructure as a service provider and critical IT software. Customers are advised to assess both intellectual property protection and supply chain integrity strategies. Part one of this blog series details initial McAfee defensive guidance and response actions. Part two will describe additional mitigation and solution recommendations.

Protection Summary

For the latest information on McAfee see KB93861and subscribe to receive updates. Below is protection summary to date for the known backdoor indicators

• GTI Cloud and latest DAT has coverage for known indicators and C2 domains for the backdoor
• McAfee Web Gateway can block known C2 domains
• McAfee is continuing to review other detection approaches, including Real Protect and Endpoint Detection and Response
• McAfee Advanced Threat Researchers continue to hunt for new indicators. Intelligence updates will be made available in MVISION Insights
• Signatures are available for Network Security Platform to detect network indicators of compromise

McAfee Labs will continue analysis for any known indicators associated with this attack and update product protection accordingly.  Furthermore, analysis is underway to analyse the behavioural components of the campaign and ensure product efficacy considers protection beyond static measures such as signatures. 

Threat Intelligence Summary

MVISION Insights is tracking the campaign as SolarWinds Supply Chain Attack Affecting Multiple Global Victims with SUNBURST Backdoor.  Customers can view the public version of MVISION Insights for the latest attack details, prevalence, techniques used and indicators of compromise.

Insights provides the indicators used by SUNBURST. The indicators will continue to update based on automated collection and human analysis. You can use the indicators to hunt on your network.  Note: This will be updated as new indicators are verified.

Insights outlines the MITRE Att&ck techniques used by SUNBURST. You can use MITRE Att&ck framework to asses defensive capability across your security architecture.

HUNTING FOR THE BACKDOOR INDICATORS

One of the first initial response actions should be to hunt for known indicators of the attack. You can use MVISION EDR or MAR to search endpoints for SUNBURST backdoor indicators as provided by Microsoft and FireEye. See the search syntax below. If you are licensed for MVISION Insights this query will take place automatically. Additional defensive guidance will be published in an upcoming blog.

Begin MVEDR Query Syntax…

Files name, full_name, md5, sha256, created_at, create_user_name, create_user_domain and HostInfo hostname, ip_address, os and LoggedInUsers username, userdomain where Files sha256 equals “ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c” or Files sha256 equals “c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77” or Files sha256 equals “eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed” or Files sha256 equals “dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b” or Files sha256 equals “32519685c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “d0d626deb3f9484e649294a8dfa814c5568f846d5aa02d4cdad5d041a29d5600” or Files sha256 equals “53f8dfc65169ccda021b72a62e0c22a4db7c4077f002fa742717d41b3c40f2c7” or Files sha256 equals “019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134” or Files sha256 equals “ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6” or Files sha256 equals “32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “292327e5c94afa352cc5a02ca273df543f2020d0e76368ff96c84f4e90778712” or Files sha256 equals “c15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71”

…End MVEDR Query Syntax

You should also search McAfee Web Gateway logs (or other network and SIEM logs) for communication to command and control domains or IP addresses, particularly those categorized as “Malicious Sites” below. Continue to check MVISION Insights for new domains and URLs.

What’s Next

It’s important to note that ongoing analysis will be critical to understand how the attackers will adapt and what additional mitigation is required. This will be a continuous process and we expect to add multiple updates to KB93861. Additionally, customers should follow McAfee Labs posts, check Insights Public Dashboard for latest threat intelligence, and continually check the Knowledge Center for latest product guidance. Part two of this blog will cover defensive capabilities and controls in more depth.

Additional McAfee Threat Intel Resources

Insights Trending Campaigns

Every week Insights Preview highlights the top emerging threats and campaigns based on ATR Operational Intelligence collection and analysis.

Atlas Dashboard

Follow the latest COVID Threat statistics on the public Atlas Dashboard.  For more information about how a customer can utilize Atlas and Intelligence as a Service from APG, speak to your McAfee Account Manager for a Threat Intel Briefing and Workshop.

Threat Research

McAfee Labs and Advanced Threat Research teams produce regular research reports with the latest threat intelligence statistics and trends. Please share the reports with customers.

McAfee Threat Intelligence Blogs

Review and Share our external blogs that feature deeper malware analysis and explanations on emerging threats and attack campaigns.

The post SUNBURST Malware and SolarWinds Supply Chain Compromise appeared first on McAfee Blogs.

Additional Analysis into the SUNBURST Backdoor

Executive Summary

There has been considerable focus on the recent disclosures associated with SolarWinds, and while existing analysis on the broader campaign has resulted in detection against specific IoCs associated with the Sunburst trojan, the focus within the Advanced Threat Research (ATR) team has been to determine the possibility of additional persistence measures. Our analysis into the backdoor reveals that the level of access lends itself to the assumption that additional persistence mechanisms could have been established and some inferences regarding the intent from adversaries;

• An interesting observation was the check for the presence of SolarWinds’ Improvement Client executable and it’s version “3.0.0.382”. The ImprovementClient is a program that can collect considerable information such as count of Orion user accounts by authentication method and data about devices and applications monitored.
• Observation of the http routine was the search for certain keywords in the http-traffic that might indicate the adversary was looking into details/access of Cloud and/or wireless networks of their victims.
• Even if a victim is using a Proxy-server with username and password, the backdoor is capable of retrieving that information and using it to build up the connection towards the C2.

Available Resources

Although this analysis will focus on the premise that the backdoor supports the feasibility of establishing additional persistence methods we recognize the importance of providing assurance regarding coverage against available indicators. To that end the following resources are available:

• KB93861: McAfee coverage for SolarWinds Sunburst Backdoor:
  https://kc.mcafee.com/corporate/index?page=content&id=KB93861 
• SUNBURST Malware and SolarWinds Supply Chain Compromise : Detailing the protection summary, but also how to use MVISION EDR or MAR to search for SUNBURST: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/sunburst-malware-and-solarwinds-supply-chain-compromise/  
• MVISION Insights Campaign: SolarWinds Supply Chain Attack Affecting Multiple Global Victims With SUNBURST Backdoor. This resource provides up to date tracking on the prevalence of available indicators based on geography and sector of potential targets: https://www.mcafee.com/enterprise/en-us/lp/insights-preview.html# 

Additional resources will become available as analysis both conducted by McAfee researchers, and the wider community becomes available.

Backdoor Analysis

There exists excellent analysis from many of our industry peers into the SUNBURST trojan, and the intention here is not to duplicate findings but to provide analysis we have not seen previously covered. The purpose is to enable potential victims to better understand the capabilities of the campaign in an effort to consider the possibility that there are additional persistence mechanisms.

For the purposes of this analysis our focus centered upon the file “SolarWinds.Orion.Core.BusinessLayer.dll“, this particular file, as the name suggests, is associated with the SolarWinds ORION software suite and was modified with a class added containing the backdoor “SunBurst”.

A deeper dive into the backdoor reveals that the initial call is to the added class “OrionImprovementBusinessLayer” which has the following functions:

The class starts with a check to see if the module is running and, if not, it will start the service and thereafter initiate a period of dormancy.

As was detailed by FireEye, this period of sleep can range from minutes up to two weeks. The actual time period of dormancy is dependent on the checks that must be passed from the code, like hash of the Orion process, write-times of files, process running etc. A sleep period of this length of time is unusual and speaks to a very patient adversary.

The most important strings inside the backdoors are encoded with the DeflateStream Class of the .NET’s Compression library together with the base64 encoder. By examining the block-list, we discover findings that warrant further inspection. First entries are the local-IP address ranges and netmasks:

• 10.0.0.0 255.0.0.0
• 172.16.0.0 255.240.0.0
• 192.168.0.0 255.255.0.0

Followed by the IPv6 local addresses equivalents:
fc00::,fe00::, fec0::,ffc0::,ff00::,ff00::

Next, there is a list of IP-addresses and their associated subnetmasks. We executed a whois on those IP-addressees to get an idea of whom they might belong to. There is no indication as to the reason that the following IPs have been inserted into the blocklist, although the netmasks implemented in certain entries are ‘quite’ specific, therefore we have to assume the attackers were intentional in their desire to avoid certain targets.

Assuming that the victim is not within the block list, the sample will then proceed to create the named pipe 583da945-62af-10e8-4902-a8f205c72b2e. This is done to ensure that only one instance of the backdoor is running. We were able to verify this through replication we carried out within our own environment.

When we ran the backdoor, we were able to confirm that this value is hardcoded in the code, and once the dormancy period passed the service is started and named pipe is created. At this point, the backdoor will also create a unique UserID MD5 value for the system it is installed on as depicted within figure 5.

This particular routine will initially read the Device-info of the system but ignore the loopback interfaces (part of the code of the ReadDeviceInfo routine that mentions “Select * From Win32_NetworkAdapterConfiguration where IPEnabled=true” ). The Device-info will then be combined with the domain name, followed by a value from the registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography). This information is then used to create an MD5 value of that string.

The module will start the ‘update’ routine. This routine is a continuous loop designed for verification against, for example, unwanted services that could potentially be used against detection of the backdoor as depicted in figure 6.

Information Gathering

The backdoor gathers information from the system. The following information is gathered by a routine called “CollectSystemDescription”, some examples include;

• OS version, major /minor – is it 32 or 64 bits
• Network configs, info on IP, NetBIOS, IPV6 etc.
• Host, SID & Username & System directory. In particular the SID for the Administrator account is searched for.

There exists other subroutines to collect additional data, for example enumerating the information from the network-adaptors, the backdoor uses the GetNetworkAdapterConfiguration routine. The routine is gathering the following information:

In order to check if certain ‘unwanted’ services are running, the backdoor enumerates the services, creates a hashlist and compares them with a hard-coded set of these values. The ‘update’ routine will exit once a ‘block-listed’ process id discovered. The backdoor will attempt to stop these services by entering a value in the registry for that service that will disable that service. The update routine will check again and continue this process until all unwanted processes are disabled.
Another capability of the backdoor is to start/stop tasks:

Other functionalities we observed in the code are:

• SetTime
• CollectSystemDescription
• UploadSystemDescription
• GetProcessByDescription
• GetFileSystemEntries
• WriteFile
• FileExists
• DeleteFile
• GetFileHash
• ReadRegistryValue
• SetRegistryValue
• DeleteRegistryValue
• GetRegistrySubKeyAndValueNames
• Reboot

An interesting observation was the check for the presence of SolarWinds’ Improvement Client executable and it’s version “3.0.0.382”.

The ImprovementClient is a program that can collect the following information (source SolarWinds) :

• The SWID (SolarWinds ID) associated with any SolarWinds commercial licenses installed
• The email address provided to the installer during installation
• Unique identifier of the downloaded installer
• Versions of all Orion products installed
• Operating system version
• CPU description and count
• Physical memory installed and percent used
• Time zone
• Dates when you logged in to the Orion website
• Licensing information of other SolarWinds Orion products locally installed
• Row counts for database tables
• Count of monitored nodes by polling protocol
• Count of Orion user accounts by authentication method
• Network discovery scheduling information (not results)
• Data about devices and applications monitored:
  • Vendor
  • Model
  • OS/Firmware version
  • Count
  • Abstract configuration information, such as number of websites hosted
• Data about the SolarWinds product:
  • Feature usage statistics
  • Performance statistics
  • Hardware and OS platform description

Another observation of the http routine was the search for certain keywords in the http-traffic that might indicate the adversary was looking into details/access of cloud and/or wireless networks of their victims by using the SolarWinds’ modules that are installed to monitor/administer these kinds of instances. Managing the network using SolarWinds’ Orion is executed by using a browser and localhost that is hosting the webserver. Reading out the certificate values and search for these keywords in the http-traffic would have gained this information.

Network / DGA

After all checks and routines have passed, the backdoor will use a domain generating algorithm (hereafter DGA) to generate a domain. Example of the part of the DGA code:

When the domain is successfully reached, the routine called ‘Update’ contains a part that will act on this and start a new thread firing off the routine “HttpHelper.Initialize”. In the below screenshot we can observe that flow:

The code shows that when the dnsrecord equals the domain and can be reached, the new thread will start in the background.

The ‘HttpHelper’ class/routine is responsible for all the C2 communications:

Even if a victim is using a Proxy-server with username and password, the backdoor is capable of retrieving that information and using it to build up the connection towards the C2. It then uses a routine called “IWebProxy GetWebProxy” for that:

The DGA-generated C2s are subdomains of: avsvmcloud[.]com.
An example of how these domains would look:

• 02m6hcopd17p6h450gt3.appsync-api.us-west-2.avsvmcloud.com
• 039n5tnndkhrfn5cun0y0sz02hij0b12.appsync-api.us-west-2.avsvmcloud.com
• 043o9vacvthf0v95t81l.appsync-api.us-east-2.avsvmcloud.com
• 04jrge684mgk4eq8m8adfg7.appsync-api.us-east-2.avsvmcloud.com
• 04r0rndp6aom5fq5g6p1.appsync-api.us-west-2.avsvmcloud.com
• 04spiistorug1jq5o6o0.appsync-api.us-west-2.avsvmcloud.com

Inspecting the CNAME’s from the DGA-generated C2’s we observed the following domain-names:

• freescanonline[.]com
• deftsecurity[.]com
• thedoccloud[.]com
• websitetheme[.]com
• highdatabase[.]com
• incomeupdate[.]com
• databasegalore[.]com
• panhardware[.]com
• Zupertech[.]com
• Virtualdataserver[.]com
• digitalcollege[.]org

In the forementioned HTTP handler code, we discovered paths that might be installed on the C2’s for different functions:

• swip/upd/
• swip/Events
• swip/Upload.ashx

Once the backdoor is connected, depending on the objectives from the adversaries, multiple actions can be executed including the usage of multiple payloads that can be injected into memory. At the time of writing, details regarding the ‘killswitch’ against the above domain will prevent this particular backdoor from being operational, however for the purpose of this analysis it demonstrates the level of access afforded to attackers. While the efforts to sinkhole the domain are to be applauded, organisations that have been able to identify indicators of SUNBURST within their environment are strongly encouraged to carry out additional measures to provide themselves assurances that further persistent mechanisms have not been deployed.

The post Additional Analysis into the SUNBURST Backdoor appeared first on McAfee Blogs.

How A Device to Cloud Architecture Defends Against the SolarWinds Supply Chain Compromise

In a blog post released 13 Dec 2020, FireEye disclosed that threat actors compromised SolarWinds’s Orion IT monitoring and management software with a trojanized version of SoalrWinds.Orion.Core.BusinessLayer.dll delivered as part of a digitally-signed Windows Installer Patch. The trojanized file delivers a backdoor, dubbed SUNBURST by FireEye (and Solorigate by Microsoft), that communicates to third-party servers for command and control and malicious file transfer giving the attacker a foothold on the affected system with elevated privileges. From there, additional actions on the objective, such as lateral movement and data exfiltration, are possible. Since release of the initial blog from FireEye, subsequent additional analysis by McAfee and the industry as well as alerts by CISA, we have seen the attack grow in size, breadth and complexity. We will continue to update defensive recommendation blogs like this as new details emerge.

The use of a compromised software supply chain as an Initial Access technique (T1195.002) is particularly dangerous as the attack uses assumed trusted paths and as such can go undetected for a long period. This attack leveraged several techniques, such as trusted software, signed code and stealthy hiding-in-plain-sight communication, allowing the attacker to evade even strong defenses and enjoy a long dwell before detection. The sophisticated nature of the attack suggests that an Advanced Persistent Threat (APT) Group is likely responsible. In fact, FireEye is tracking the group as UNC2452 and has released countermeasures to identify the initial SUNBURST backdoor. McAfee has also provided an intelligence summary within MVISION Insights and mitigation controls for the initial entry vectors are published in KB93861. For additional response actions, please view Part One of this blog series here. If you are using SolarWinds software, please refer to the company guidance here to check for vulnerable versions and patch information.

However, looking beyond the initial entry and containment actions, you should think about how you are prepared for this type of attack in the future. This is a sophisticated actor(s) who may use other techniques such as Spearphishing to gain access, then move around the corporate network and potentially steal intellectual property as was the case with FireEye. They will change techniques and tools, so you need to be ready. Our Advanced Threat Research team tracks over 700 APT and Cyber Crime campaigns so the potential for another threat actor to launch a similar attack is high. In this blog, we will take a specific look at the techniques used in the SolarWinds compromise and provide some guidance on how McAfee solutions could help you respond now and prepare for this type of threat in the future with an adaptable security capability for resilience.

Attack Chain Overview

In our first blog in this series, we provided some initial response guidance designed to disrupt the attack early in the Execution phase or look retrospectively on the endpoints or proxy logs for indicators of compromise. But as you can see in the attack timeline below, it started much earlier with purposeful and detailed preparation and includes multiple other steps. A couple of techniques speak volumes about the sophistication and planning involved in this campaign.

First is the choice of entry vector. The attacker in this case compromised part of the software supply chain by weaponizing software by SolarWinds, a major brand of IT management software. While software supply chain compromises are not new, like the recent one affecting JavaScript, they are typically on a smaller scale or more quickly detected. More common initial access techniques involve Spearphishing or taking advantage of open remote services like RDP. While both take planning and effort, weaponizing software from a major technology company and going undetected in that process is no easy feat. Secondly, the calculated wait time before external communication and the custom Domain Generation Algorithm (DGA) indicate the attacker has a lot of patience and stealth capability. For more detailed analysis of these advanced techniques, see McAfee Labs additional analysis blog on the SUNBURST backdoor.

The attack also involves numerous post-exploitation actions such as command and control communication masquerading (T1001.003) as normal update traffic, additional payload transfers (T1105), system discovery, credential harvesting and potentially then movement to other systems, even cloud-hosted infrastructure systems. The goal of course is to disrupt or detect any stage of attack before the breakout point and hopefully before any real impact to the business. The breakout point is when an attacker has gained privileges and starts to move laterally within the business. At that point, it becomes very difficult but not impossible to disrupt or detect the activity. But you must act fast. The impact of the attack can vary. In one case, it could be loss of intellectual property, but in another case, destruction of critical systems or data could be the goal. Also, what if the attacker used other initial access techniques, such as Spearphishing (T1566), to deliver a similar backdoor? Would you be able to detect that activity or any of the follow actions? Our point is don’t just update the endpoint with the latest DAT and consider yourself secure. Look for other ways to disrupt or detect an attack throughout the whole attack chain, leveraging both prevention and detection capability and keeping the end goal in mind to reduce impact to the business. Also think about how you prepare. The attackers in this case spent a lot of time in preparation creating custom malware and infrastructure. How about your organization? Do you know what attackers might be targeting your organization? Do you know their tactics and techniques?

Staying Ahead with MVISION Insights

In the first hours of a new threat campaign, if the CIO or CISO asked you, “are we exposed to SUNBURST”, how long would it take you to answer that question? One place to turn is MVISION Insights. 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 700 APT and Cyber Crime campaigns as researched by McAfee’s ATR team, including the most recent, FireEye Red Team tool release and SolarWinds Supply Chain Compromise campaigns.

In the beginning hours of a new threat response, you can use MVISION Insights to get a quick summary of the threat, view external resources, and a list of known indicators such as files, URLs, or IP addresses. The campaign summary saves you from some of the time-consuming task of combing multiple sites, downloading reports, and building out the broader picture. MVISION Insights provides critical pieces in one place allowing you to move quicker through the response process. The next question to answer, is this new attack a risk to my business? Insights can help you answer that question as well when you click on “Your Environment”.

Insights automatically correlates the indicators of compromise with Threat Events from McAfee ENS, allowing you to quickly asses if there is an immediate problem now. If you had a detection, you should immediately go to incident response. Insights reviews your endpoint control configuration to asses if you have the right content update deployed to potentially disrupt the threat. At this point, you are closer to answer the CIO question of “are we exposed”. I say closer because Insights provides only the endpoint protection view currently so you will need to review other controls you have in place to fully assess risk.

However, Insights also assesses your endpoint security posture against other advanced threat techniques, looking to see if you are getting the best value from ENS by leveraging signature, intelligence and behavior anomaly detection capability in the solution. This is important because the attackers will change tactics, using new entry techniques and tools, so your security posture must continuously adapt. And this is just one campaign. Insights is summarizing intelligence, surfacing detections and reducing your attack surface continuously, against 700 campaigns!

Review your Defensive Architecture

Mitigating risk from SUNBURST and similar sophisticated APT campaigns requires a security architecture that provides defense in depth and visibility throughout the entire attack chain. You should review your architecture and assess gaps either in technique visibility or protection capability. Below we have outlined where McAfee and partner solutions could be used to either disrupt or detect some of the attack techniques used in SUNBURST based on what we know today.

While the attacker is no doubt sophisticated and stealthy, the multi-stage aspect of the attack presents opportunities to detect or stop at multiple points and perhaps even before the attack gains a foothold. We cover more about how to use McAfee EDR to search for or detect some of the techniques used in SUNBURST in next section. However, there are some other key cyber defense capabilities that may be overlooked in your organizations but are critical to having a chance at detection and mitigation. We highlight those in this section below.

Getting inside the attacker’s preparation

Normally this is beyond what most organizations have time to do. However, in this case, you need to gain any advantage. We discussed MVISION Insights above so here we will cover additional guidance. During the preparation phase of this attack, the attacker obtains infrastructure within the target geo to host their command and control server. During this phase, they also set the hostnames of their C2 servers to mimic target organization hostnames. A scan for your domain names on external IP blocks can reveal the attack formation. Open source tools such as Spiderfoot offer a number of plugins to gather and analyze such types of data. Passive DNS with combination of hosts communicating with unusual domain names also represent a window of detection whereby Advanced DNS Protection solutions such as from our SIA partner Infoblox can detect behavior-based DGA usage by malware and automatically block such DNS resolution requests.

Visibility on DNS

DNS queries often provide the first layers of insights into any type of C2 communication and data exfiltration. You should enable logging ideally at an upstream resolver(s) where you can see traffic from your entire infrastructure. More information can be found here for Windows DNS Servers and Linux Bind DNS Servers.  This could be forwarded to McAfee ESM/other SIEMs for analysis and correlation for detection of DGA-type activities.

NetFlow Logging

Being able to detect unusual flows should also be a priority for incident responders. Along with DNS queries, NetFlow data when combined with UBA provides a great source of detection, as the attackers’ use of VPS providers can be combined with user login data to detect an “impossible rate of travel event.”

Hunting for Indicators with MVISION EDR

As described in the defensive architecture, MVISION EDR plays a vital role in hunting for prevalence of indicators related to the SUNBURST backdoor and ensuing post compromise activity. The role of MVISION EDR becomes even more important due to the usage of manual OPSEC by the threat actor where what follows the initial breach is driven by how the threat actor is targeting the organisation.

Hunting for Presence of Malicious Files

You can use MVISION EDR or MAR to search endpoints for SUNBURST indicators as provided by Microsoft and FireEye. If you are licensed for MVISION Insights, you can pivot directly to MVISION EDR to search for indicators. MVISION EDR supports real-time searches to hunt for presence of files on the endpoints and allows for sweeps across the estate. The following query can be used with the pre-populated malicious file hash list. The presence of the file on the system is itself does not mean it was successful and further hunting to check for execution of the actual malicious code on the system.is needed. See the search syntax below.

Begin MVEDR Query Syntax…

Files name, full_name, md5, sha256, created_at, create_user_name, create_user_domain and HostInfo hostname, ip_address, os and LoggedInUsers username, userdomain where Files sha256 equals “ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c” or Files sha256 equals “c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77” or Files sha256 equals “eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed” or Files sha256 equals “dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b” or Files sha256 equals “32519685c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “d0d626deb3f9484e649294a8dfa814c5568f846d5aa02d4cdad5d041a29d5600” or Files sha256 equals “53f8dfc65169ccda021b72a62e0c22a4db7c4077f002fa742717d41b3c40f2c7” or Files sha256 equals “019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134” or Files sha256 equals “ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6” or Files sha256 equals “32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “292327e5c94afa352cc5a02ca273df543f2020d0e76368ff96c84f4e90778712” or Files sha256 equals “c15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71”

…End MVEDR Query Syntax

Additionally, you can do a historical search creation and deletion of files going back up to 90 days in cloud storage.

The threat actor is known to rename system utilities/files and clean up their tracks. MVISION EDR can review historical changes to the file system, this is crucial in determining if an endpoint was a victim of this attack. The flexible search interface can be used to filter down and track the progress of the completion of the attacker’s objectives for e.g. look at changes triggered from the infected dll’s such as netsetupsvc.dll.

Hunting for Malicious Network Connections

MVISION EDR allows for tracing of active network connections leveraging the real time search functionalities

You can also leverage the historical search function to look for historical connections related to the command and control activity for this threat actor. The filtering by process ID and source/destination IP allows analysts to track down the malicious communications.

MVISION EDR also allows analysts to review historical DNS lookups thus allowing for the ability to hunt for malicious DNS lookups. This is a very important capability in the product as many organizations do not log DNS or have a DNS hierarchy that makes it harder to log the end device making the actual request.

Hunting for Malicious Named Pipes Across the Estate

MVISION EDR includes custom collector creation ability that allows for execution of custom commands across the estate. In this case, it’s possible to look for the existence of the Named Pipes by executing the following Powershell command:

Powershell Command for Pipe detection [System.IO.Directory]::GetFiles(“\\.\\pipe\\”) | %{($_ -split “\\”)[6]}

HostInfo hostname, ip_address, os where _NamedPipe pipename contains “583da945-62af-10e8-4902-a8f2 05c72b2e”

Hunting for Malicious Processes

It is known the attacker in its final stages leverages legitimate SolarWinds processes to complete their objectives:

\Windows\SysWOW64\WerFault.exe

\SolarWinds\Orion\ExportToPDFCmd.Exe

\SolarWinds\Orion\APM\APMServiceControl.exe

\SolarWinds.Credentials\SolarWinds.Credentials.Orion.WebApi.exe

\SolarWinds\Orion\Topology\SolarWinds.Orion.Topology.Calculator.exe

\SolarWinds\Orion\Database-Maint.exe

ProcessHistory parentname, name, id, cmdline WHERE ProcessHistory parentname equals “WerFault.exe” or ProcessHistory parentname equals “ExportToPDFCmd.Exe” or ProcessHistory parentname equals “APMServiceControl.exe” or ProcessHistory parentname equals “SolarWinds.Credentials.Orion.WebApi.exe” or ProcessHistory parentname equals “SolarWinds.Orion.Topology.Calculator.exe” or ProcessHistory parentname equals “\SolarWinds\Orion\Database-Maint.exe”

Hunting back longer than 90 days with EDR Trace Data

MVISION EDR’s architecture leverages the Data Exchange Layer to stream trace data to our cloud service where we apply analytics to identify or investigate a threat. Trace data are artifacts from the endpoint, such as file hashes, processes, communications, typically needed for endpoint detection and searches. The DXL architecture allows that data to be streamed to the cloud as well to a local data store such as a SIEM or other log storage like Elastic simultaneously.

You can store the data longer than the 90-day maximum McAfee stores in our cloud. Why is this important? Recent analysis of SUNBURST suggests that the attack goes as far back as March 2020, and perhaps earlier. This local storage would provide capability to hunt for indicators further back as needed, if so configured.

Assessing Visibility

How do you know what data sources are needed to detect Mitre Att&ck tactics and techniques? Carlos Diaz from MVISION EDR engineering wrote a great tool called Mitre-Assistant to simplify that process. You can download that tool here.

Detecting Actions on Objective

Post Initial Exploit Threat Detection and Analysis in EDR

One of the key challenges threat hunters and security analysts face is where the attack progresses through to the second phase of the attack, where it is understood the attacker has dropped malware to execute and complete their objectives. This usage of sophisticated execution of malware from a trusted process is detected by MVISION EDR and automatically mapped to the MITRE ATT&CK Framework. As part of the detection and process tracing, EDR also captures the command executed on the endpoint. This becomes invaluable in case of tracking the manual OPSEC aspect of the second phase of the attack.

MVISION EDR provides extensive capabilities to respond to threats once they have been assessed, e.g. real-time searches once executed allows analysts to scope the affected endpoints rapidly at which point the solution offers multiple options as a method for containment and remediation of the threat across the estate through bulk operations.

Detecting Data Exfiltration, Lateral Movement and Prevention

MVISION EDR provides a way to easily visualize data egress by looking at topology view of the endpoints where malicious activity has been detected, by observing the network-flow map the outlier connections can be easily identified and then correlated with WHOIS, IP reputation and Passive DNS data from providers like McAfee GTI and Virustotal. Once established, the external connections can be blocked and the endpoint can be quarantined from the EDR console. EDR also shows common processes spawning across multiple endpoints to showcase lateral movement and is also tagged as part of the MITRE techniques being identified and detected.

Combining EDR with Deception technology such as that from Attivo Networks brings together a combination of offensive detection where the attacker can be effectively trapped as result of not getting hold of the real credentials required to make the lateral movement/ privilege escalation a success thus failing in their objective completion.

An integrated approach to DLP can also provide effective protection against the completion of the objectives for e.g. unified DLP policy across the endpoint and web-gateway looking for exfiltration of sensitive organizational data can also provide valuable defenses. McAfee’s UCE platform provides such unified data protection capabilities.

Cloud account compromise detection

Our latest research indicates attacker is actively looking to establish additional footholds into customer cloud environments such as Azure AD or bypass multi-factor authentication by hijacking SAML sessions, McAfee’s MVISION Cloud Access Control and User Anomaly Detection can identify suspicious access attempts to cloud services and infrastructure.

It is recommended to increase monitoring and investigations into such activity especially with privileged accounts on sensitive infrastructure

Supply Chain and Intellectual Property Protection

In addition to architecture review and continuous hunting for indicators, it is recommended that customers work with their suppliers – IT, Cloud Services, Infrastructure, Hardware, etc. – to validate integrity. Secondly, review controls, detection use cases in the SOC and logs, specifically related to your intellectual property. A tabletop exercise to rehearse crisis management and breach notification procedures is also recommended.

Summary and Next Steps

It’s important to note that analysis of this attack is ongoing across the globe and events are still unfolding. The presence/detection of the backdoor and affected software is just the beginning for many customers. MVISION EDR or other tool detections of malicious named-pipe presence and domains help indicate to a customer if the backdoor was running, but with the gathered system information, the adversary may have valid accounts and access to AD or Cloud systems in some cases. The adversary has been wiping information/log files to erase traces. Incident Response is a critical piece of your overall business resilience and if you are affected, you will no doubt be asking yourself these types of questions.

• When did we install the vulnerable software?
• Did they compromise user-accounts and have AD access?
• Did they install additional backdoors?
• How many systems and accounts are affected?
• Were cloud or enterprise resources accessed?
• Was information stolen? If so, do we have notification procedures?
• Are there other supply chain compromises yet undiscovered?

McAfee will continue to post analysis results and defensive guidance as we learn more about the attack. Customers should follow McAfee Labs posts, check the Insights Preview Dashboard for latest threat intelligence, and continually check the Knowledge Center for latest product guidance.

The post How A Device to Cloud Architecture Defends Against the SolarWinds Supply Chain Compromise appeared first on McAfee Blogs.

2020 In Review: The Top 10 Most Popular Life at McAfee Blogs

2020 has been quite the year for many, and through it all, we’re reflecting on everything we are thankful for. This includes the incredible stories and invaluable perspectives that come from our McAfee team members around the world.

As the year ends, we’re counting down the top 10 most read Life at McAfee blog stories. These are the stories from our team members that you love to read, and we love to tell!   

10. One Team Member Selflessly Provides Relief to Covid 19’s Front Line 

When COVID-19 hit Germany, Heiko jumped into action and made an impact on his community with the help of THW and McAfee’s Volunteer Time Off (VTO) benefit. Read about Heiko’s experience and how he was able to help provide relief by helping to build a temporary hospital facility. 

9. How to Adopt a Work-From-Home Mindset 

Navigating a global pandemic while balancing parenthood and adjusting to remote work is currently a challenge for many. In this blog, our team member, Paige, offers up four helpful tips for remote working parents. 

 8. McAfee Men Share Fresh Perspectives on Gender Equality

In honor of International Women’s Day, we asked McAfee men around the world to share their perspectives on creating a more gender equal world. They offered candid and rich insights with takeaways to remember — inside and outside of the workplace. If you’re looking for an interesting conversation on gender equality, you won’t want to miss this blog. 

7. McAfee’s Women in Security Offer New Grads Career Insights

Launching your career is an exciting experience that can also be a nerve-wracking feat. Our Women in Security (WISE) Community hosted a panel discussion to encourage our next generation of women in tech to pursue their passions. Whether you’re just starting your career or looking for a change, you’ll find useful insights on what it’s like to work in the tech industry and life at McAfee!  

6. Spotlighting McAfee’s Women in Technology Scholarship Recipients

We talked to our Women in Technology (WIT) Scholarship recipients and discussed their participation in our summer internship program in Cork, Ireland. Read about their unique experiences being in the program — from building professional relationships to mentorships and training. This is a valuable read for anyone jumpstarting a new career.

5. What is a McAfee Internship Like? 10 Interns Share Perspectives 

Looking for a snapshot of McAfee internships? To celebrate National Intern Day, we asked  ten global McAfee interns to share insights gained from their unique experiences. 

4. Honoring Our Brave Military Veterans from the McAfee Community 

 To pay tribute to our veterans in honor of Veterans Day and Remembrance Day, we asked team members in our McAfee Veterans Community to share memories and photos from their service days. Check out what some of them had to say! 

3. How One McAfee Advanced Threat Researcher is Giving Back During Covid-19 

Meet Thomas, Advanced threat Researcher at McAfee by day, 3D–mask–printing expert by night. Read Thomas’ story and find out how he is making a significant impact and inspiring others to support healthcare workers during the pandemic. 

2. Women in Sales Part 1: Opportunities for Women Across Cybersecurity Sales 

In our Women in Sales series, McAfee’s sales professionals talked on how to break boundaries and achieve success in cybersecurity sales. If you want to dive into industry opportunities and gain advice to advance your career, this is the place to start!

1. Five Tips from McAfee’s Remote Workers

Whether you’re an expert in remote work or working from home for the first time, you may be looking for helpful tips to set yourself up for success. In this blog, get advice from seasoned remote workers on navigating working from home and learn how you can incorporate practical tips.  

The post 2020 In Review: The Top 10 Most Popular Life at McAfee Blogs appeared first on McAfee Blogs.

McAfee Security Innovation Alliance 2020 MPOWER Awards

McAfee, the device-to-cloud cybersecurity company, announced the winners of its distinguished SIA Partner Awards. The 2020 awards recognize partners who demonstrated innovation, strategic value, and market leadership in their respective market segments which are a complement to the McAfee solution portfolio.

2020 has been a difficult year for everyone that has required organizations to be flexible and rethink how they deploy security to ensure their critical assets remain protected. The McAfee SIA program enables organizations to embrace the flexibility they need through certified integrated solutions from industry-leading providers to ensure they have the tools and resources needed to stay protected and ensure business keeps operating.

We are pleased to announce the winners of the 2020 McAfee Security Innovation Alliance Awards in the following three categories: Most Innovative Partners of the Year, and SIA Partner of the Year.

Most Innovative Partner of the Year: IBM Security

IBM Security is a strategic partnered with McAfee across multiple IBM teams including Resilient and QRadar. To date McAfee has certified integrations with IBM’s Incident Response platform, Resilient to include: TIE, DXL, ePO, ESM, ATD and now MVISION. McAfee has released QRadar integrations to both ePO and MVISION. All McAfee Resilient integrations are published on IBM’s AppExchange. In 2019 McAfee and IBM jointly founded the Open Cybersecurity Alliance under the auspices of Oasis. Read our  solution brief for more details. IBM Security was amongst the inaugural partners announced during the recent launch of the MVISION Marketplace.

Most Innovative Partner of the Year: Siemplify

Siemplify is a great McAfee partner, previously integrating their SOAR product with McAfee ePO. Now, with McAfee’s latest announcement of the MVISION Marketplace including Siemplify as one of the inaugural development partners. Siemplify has shown themselves to be one of our most innovative partners during 2020 and now enable mutual customers to discover, try, buy, and deploy partner technologies as a Composable solution with a few clicks of the mouse.

SIA Partner of the Year 2020 : ThreatQuotient

Most Valuable Partner of the Year criteria cover the breadth and depth of the partner’s multiple integrations and close business engagement with McAfee.

ThreatQuotient, “ThreatQ” Joined the SIA program in January 2017 and quickly showed their value through their Threat Intelligence Platform. In ThreatQ fashion, they quickly, integrated with McAfee TIE, McAfee Data Exchange Layer (DXL), McAfee Advanced Threat Detection (ATD), McAfee Active Response (MAR) and Enterprise Security Manager (ESM), followed by MVISION Endpoint Detection and Response (EDR). Most recently ThreatQ was amongst the inaugural partners to launch with McAfee’s new MVISION Marketplace.

Partnership integrations and the most deal closures within the SIA programs tells the story or why ThreatQuotient was selected as the Partner of The Year.

To learn more about these partners and MVISION Marketplace visit: https://marketplace.mcafee.com

Read the MVISION Marketplace press release here: McAfee Announces MVISION Marketplace

The post McAfee Security Innovation Alliance 2020 MPOWER Awards appeared first on McAfee Blogs.

2021 Threat Predictions Report

The December 2020 revelations around the SUNBURST campaigns exploiting the SolarWinds Orion platform have revealed a new attack vector – the supply chain – that will continue to be exploited.

The ever-increasing use of connected devices, apps and web services in our homes will also make us more susceptible to digital home break-ins. This threat is compounded by many individuals continuing to work from home, meaning this threat not only impacts the consumer and their families, but enterprises as well.

Attacks on cloud platforms and users will evolve into a highly polarized state where they are either “mechanized and widespread” or “sophisticated and precisely handcrafted”.

Mobile users will need to beware of phishing or smishing messages aimed at exploiting and defrauding them through mobile payment services.

The use of QR codes has notably accelerated during the pandemic, raising the specter of a new generation of social engineering techniques that seek to exploit consumers and gain access to their personal data.

Finally, the most sophisticated threat actors will increasingly use social networks to target high value individuals working in sensitive industry sectors and roles.

A new year offers hope and opportunities for consumers and enterprises, but also more cybersecurity challenges. I hope you find these helpful in planning your 2021 security strategies.

–Raj Samani, Chief Scientist and McAfee Fellow, Advanced Threat Research 

Twitter @Raj_Samani 

2021 Predictions  

By Steve Grobman 

The revelations around the SolarWinds-SUNBURST espionage campaign will spark a proliferation in copycat supply chain attacks of this kind.  

On December 13, 2020, the cybersecurity industry learned nation-state threat actors had compromised SolarWinds’s Orion IT monitoring and management software and used it to distribute a malicious software backdoor called SUNBURST to dozens of that company’s customers, including several high-profile U.S. government agencies.  

This SolarWinds-SUNBURST campaign is the first major supply chain attack of its kind and has been referred to by many as the “Cyber Pearl Harbor” that U.S. cybersecurity experts have been predicting for a decade and a half.  

The campaign also represents a shift in tactics where nation state threat actors have employed a new weapon for cyber-espionage.  Just as the use of nuclear weapons at the end of WWII changed military strategy for the next 75 years, the use of a supply chain attack has changed the way we need to consider defense against cyber-attacks.   

This supply chain attack operated at the scale of a worm such as WannaCry in 2017, combined with the precision and lethality of the 2014 Sony Pictures or 2015 U.S. government Office of Personnel Management (OPM) attacks. 

Within hours of its discovery, the magnitude of the campaign became frighteningly clear to organizations responsible for U.S. national security, economic competitiveness, and even consumer privacy and security.  

It enables U.S. adversaries to steal all manners of information, from inter-governmental communications to national secrets. Attackers can, in turn, leverage this information to influence or impact U.S. policy through malicious leaks.  Every breached agency may have different secondary cyber backdoors planted, meaning that there is no single recipe to evict the intrusion across the federal government. 

While some may argue that government agencies are legitimate targets for nation-state spy craft, the campaign also impacted private companies. Unlike government networks which store classified information on isolated networks, private organizations often have critical intellectual property on networks with access to the internet.  Exactly what intellectual property or private data on employees has been stolen will be difficult to determine, and the full extent of the theft may never be known.  

This type of attack also poses a threat to individuals and their families given that in today’s highly interconnected homes, a breach of consumer electronics companies can result in attackers using their access to smart appliances such as TVs, virtual assistants, and smart phones to steal their information or act as a gateway to attack businesses while users are working remotely from home. 

What makes this type of attack so dangerous is that it uses trusted software to bypass cyber defenses, infiltrate victim organizations with the backdoor and allow the attacker to take any number of secondary steps. This could involve stealing data, destroying data, holding critical systems for ransom, orchestrating system malfunctions that result in kinetic damage, or simply implanting additional malicious content throughout the organization to stay in control even after the initial threat appears to have passed. 

McAfee believes the discovery of the SolarWinds-SUNBURST campaign will expose attack techniques that other malicious actors around the world will seek to duplicate in 2021 and beyond. 

By Suhail Ansari, Dattatraya Kulkarni and Steve Povolny 

 The increasingly dense overlay of numerous connected devices, apps and web services used in our professional and private lives will grow the connected home’s attack surface to the point that it raises significant new risks for individuals and their employers. 

 While the threat to connected homes is not new, what is new is the emergence of increased functionality in both home and business devices, and the fact that these devices connect to each other more than ever before. Compounding this is the increase in remote work – meaning many of us are using these connected devices more than ever. 

In 2020,the global pandemic shifted employees from the office to the home, making the home environment a work environment. In fact, since the onset of the coronavirus pandemic, McAfee Secure Home Platform device monitoring shows a 22% increase in the number of connected home devices globally and a 60% increase in the U.S. Over 70% of the traffic from these devices originated from smart phones, laptops, other PCs and TVs, and over 29% originated from IoT devices such as streaming devices, gaming consoles, wearables, and smart lights.

McAfee saw cybercriminals increase their focus on the home attack surface with a surge in various phishing message schemes across communications channels. The number of malicious phishing links McAfee blocked grew over 21% from March to November, at an average of over 400 links per home.  

 This increase is significant and suggests a flood of phishing messages with malicious links entered home networks through devices with weaker security measures.  

 Millions of individual employees have become responsible for their employer’s IT security in a home office filled with “soft” targets, unprotected devices from the kitchen, to the family room, to the bedroom. Many of these home devices are “orphaned” in that their manufacturers fail to properly support them with security updates addressing new threats or vulnerabilities.  

This contrasts with a corporate office environment filled with devices “hardened” by enterprise-grade security measures. We now work with consumer-grade networking equipment configured by “us” and lacking the central management, regular software updates and security monitoring of the enterprise.   

Because of this, we believe cybercriminals will advance the home as an attack surface for campaigns targeting not only our families but also corporations. The hackers will take advantage of the home’s lack of regular firmware updates, lack of security mitigation features, weak privacy policies, vulnerability exploits, and user susceptibility to social engineering.  

By compromising the home environment, these malicious actors will launch a variety of attacks on corporate as well as consumer devices in 2021. 

By Sandeep Chandana  

Attacks on cloud platforms will evolve into a highly polarized state where they are either “mechanized and widespread” or “targeted and precisely handcrafted”.  

The COVID-19 pandemic has also hastened the pace of the corporate IT transition to the cloud, accelerating the potential for new corporate cloud-related attack schemes. With increased cloud adoption and the large number of enterprises working from home, not only is there a growing number of cloud users but also a lot more data both in motion and being transacted.  

 McAfee cloud usage data from more than 30 million McAfee MVISION Cloud users worldwide shows a 50% increase overall in enterprise cloud use across all industries the first four months of 2020. Our analysis showed an increase across all cloud categories, usage of collaboration services such as Microsoft O365 by 123%, increase in use of business services such as Salesforce by 61% and the largest growth in collaboration services such as Cisco Webex (600%), Zoom (+350%), Microsoft Teams (+300%), and Slack (+200%). From January to April 2020, corporate cloud traffic from unmanaged devices increased 100% across all verticals.  

 During the same period, McAfee witnessed a surge in attacks on cloud accounts, an estimated 630% increase overall, with variations in the sectors that were targeted. Transportation led vertical industries with a 1,350% increase in cloud attacks, followed by education (+1,114%), government (+773%), manufacturing (+679%), financial services (+571%) and energy and utilities (+472%).  

The increasing proportion of unmanaged devices accessing the enterprise cloud has effectively made home networks an extension of the enterprise infrastructure. Cybercriminals will develop new, highly mechanized, widespread attacks for better efficacy against thousands of heterogenous home networks.  

One example could be a widespread brute force attack against O365 users, where the attacker seeks to leverage stolen credentials and exploit users’ poor practice of re-using passwords across different platforms and applications. As many as 65% of users reuse the same password for multiple or all accounts according to a 2019 security survey conducted by Google. Where an attacker would traditionally need to manually encode first and last name combinations to find valid usernames, a learning algorithm could be used to predict O365 username patterns.  

Additionally, cybercriminals could use AI and ML to bypass traditional network filtering technologies deployed to protect cloud instances. Instead of launching a classic brute force attack from compromised IPs until the IPs are blocked, resource optimization algorithms will be used to make sure the compromised IPs launch attacks against multiple services and sectors, to maximize the lifespan of compromised IPs used for the attacks. Distributed algorithms and reinforcement learning will be leveraged to identify attack plans primarily focused on avoiding account lockouts.   

McAfee also predicts that, as enterprise cloud security postures mature, attackers will be forced to handcraft highly targeted exploits for specific enterprises, users and applications.  

The recent Capital One breach was an example of an advanced attack of this kind. The attack was thoroughly cloud-native. It was sophisticated and intricate in that a number of vulnerabilities and misconfigurations across cloud applications (and infrastructure) were exploited and chained. It was not a matter of chance that the hackers were successful, as the attack was very well hand-crafted.  

 We believe attackers will start leveraging threat surfaces across devices, networks and the cloud in these ways in the months and years ahead. 

By Suhail Ansari and Dattatraya Kulkarni

As users become more and more reliant on mobile payments, cybercriminals will increasingly seek to exploit and defraud users with scam SMS phishing or smishing messages containing malicious payment URLs.

 Mobile payments have become more and more popular as a convenient mechanism to conduct transactions. A Worldpay Global Payments Report for 2020 estimated that 41% of payments today are on mobile devices, and this number looks to increase  at the expense of traditional credit and debit cards by 2023. An October 2020 study by Allied Market Research found that the global mobile payment market size was valued at $1.48 trillion in 2019, and is projected to reach $12.06 trillion by 2027, growing at a compound annual growth rate of 30.1% from 2020 to 2027.  

Additionally, the COVID-19 pandemic has driven the adoption of mobile payment methods higher as consumers have sought to avoid contact-based payments such as cash or physical credit cards. 

But fraudsters have followed the money to mobile, pivoting from PC browsers and credit cards to mobile payments. According to research by RSA’s Fraud and Risk Intelligence team, 72% of cyber fraud activity involved the mobile channel in the fourth quarter of 2019. The researchers observed that this represented “the highest percentage of fraud involving mobile apps in nearly two years and underscores a broader shift away from fraud involving web browsers on PCs.” 

McAfee predicts there will be an increase in “receive”-based mobile payment exploits, where a user receives a phishing email, direct message or smishing message telling him that he can receive a payment, transaction refund or cash prize by clicking on a malicious payment URL. Instead of receiving a payment, however, the user has been conned into sending a payment from his account.  

This could take shape in schemes where fraudsters set up a fake call center using a product return and servicing scam, where the actors send a link via email or SMS, offering a refund via a mobile payment app, but the user is unaware that they are agreeing to pay versus receiving a refund. The figures below show the fraudulent schemes in action.  

Mobile wallets are making efforts to make it easier for users to understand whether they are paying or receiving. Unfortunately, as the payment methods proliferate, fraudsters succeed in finding victims who either cannot distinguish credit from debit or can be prompted into quick action by smart social engineering.  

Governments and banks are making painstaking efforts to educate users to understand the use of one-time passwords (OTPs) and that they should not be shared. Adoption of frameworks such as caller ID authentication (also known as STIR/SHAKEN) help in ensuring that the caller ID is not masked by fraudsters, but they do not prevent a fraudster from registering an entity that has a name close to the genuine provider of service. 

In the same way that mobile apps have simplified the ability to conduct transactions, McAfee predicts the technology is making it easier to take advantage of the convenience for fraudulent purposes. 

By Suhail Ansari and Dattatraya Kulkarni 

Cybercriminals will seek new and ever cleverer ways to use social engineering and QR Code practices to gain access to consumer victims’ personal data. 

The global pandemic has created the need for all of us to operate and transact in all areas of our lives in a “contactless” way. Accordingly, it should come as no surprise that QR codes have emerged as a convenient input mechanism to make mobile transactions more efficient.  

QR code usage has proliferated into many areas, including payments, product marketing, packaging, restaurants, retail, and recreation just to name a few. QR codes are helping limit direct contact between businesses and consumers in every setting from restaurants to personal care salons, to fitness studios. They allow them to easily scan the code, shop for services or items offered, and easily purchase them.  

A September 2020 survey by MobileIron found that 86% of respondents scanned a QR code over the course of the previous year and over half (54%) reported an increase in the use of such codes since the pandemic began. Respondents felt most secure using QR codes at restaurants or bars (46%) and retailers (38%). Two-thirds (67%) believe that the technology makes life easier in a touchless world and over half (58%) wish to see it used more broadly in the future.  

In just the area of discount coupons, an estimated 1.7 billion coupons using QR codes were scanned globally in 2017, and that number is expected to increase by a factor of three to 5.3 billion by 2022. In just four years, from 2014 to 2018, the use of QR codes on consumer product packaging in Korea and Japan increased by 83%. The use of QR codes in such “smart” packaging is increasing at an annual rate of 8% globally.  

In India, the government’s Unique Identification Authority of India (UIDAI) uses QR codes in association with Aadhaar, India’s unique ID number, to enable readers to download citizens’ demographic information as well as their photographs. 

However, the technicalities of QR codes are something of a mystery to most users, and that makes them potentially dangerous if cybercriminals seek to exploit them to target victims.  

The MobileIron report found that whereas 69% of respondents believe they can distinguish a malicious URL based on its familiar text-based format, only 37% believe they can distinguish a malicious QR code using its unique dot pattern format. Given that QR codes are designed precisely to hide the text of the URL, users find it difficult to identify and even suspect malicious QR codes. 

Almost two-thirds (61%) of respondents know that QR codes can open a URL and almost half (49%) know that a QR code can download an application. But fewer than one-third (31%) realize that a QR code can make a payment, cause a user to follow someone on social media (22%), or start a phone call (21%). A quarter of respondents admit scanning a QR code that did something unexpected (such as take them to a suspicious website), and 16% admitted that they were unsure if a QR code actually did what it was intended to do. 

It is therefore no surprise that QR codes have been used in phishing schemes to avoid anti-phishing solutions’ attempts to identify malicious URLs within email messages. They can also be used on webpages or social media. 

In such schemes, victims scan fraudulent QRs and find themselves taken to malicious websites where they are asked to provide login, personal info, usernames and passwords, and payment information, which criminals then steal. The sites could also be used to simply download malicious programs onto a user’s device.  

McAfee  predicts that hackers will increasingly use these QR code schemes and broaden them using social engineering techniques. For instance, knowing that business owners are looking to download QR code generator apps, bad actors will entice consumers into downloading malicious QR code generator apps that pretend to do the same. In the process of generating the QR code (or even pretending to be generating the correct QR code), the malicious apps will steal the victim’s sensitive data, which scammers could then use for a variety of fraudulent purposes.  

Although the QR codes themselves are a secure and convenient mechanism, we expect them to be misused by bad actors in 2021 and beyond. 

By Raj Samani 

McAfee predicts that sophisticated cyber adversaries will increasingly target, engage and compromise corporate victims using social networks as an attack vector.  

Cyber adversaries have traditionally relied heavily on phishing emails as an attack vector for compromising organizations through individual employees. However, as organizations have implemented spam detection, data loss prevention (DLP) and other solutions to prevent phishing attempts on corporate email accounts, more sophisticated adversaries are pivoting to target employees through social networking platforms to which these increasingly effective defenses cannot be applied. 

McAfee has observed such threat actors increasingly using the messaging features of LinkedIn, What’s App, Facebook and Twitter to engage, develop relationships with and then compromise corporate employees. Through these victims, adversaries compromise the broader enterprises that employ them. McAfee predicts that such actors will seek to broaden the use of this attack vector in 2021 and beyond for a variety of reasons.  

Malicious actors have used the social network platforms in broad scoped schemes to perpetrate relatively low-level criminal scams. However, prominent actors such as APT34, Charming Kitten, and Threat Group-2889 (among others) have been identified using these platforms for higher-value, more targeted campaigns on the strength of the medium’s capacity for enabling customized content for specific types of victims.  

Operation North Star demonstrates a state-of-the-art attack of this kind. Discovered and exposed by McAfee in August 2020, the campaign showed how lax social media privacy controls, ease of development and use of fake LinkedIn user accounts and job descriptions could be used to lure and attack defense sector employees. 

Just as individuals and organizations engage potential consumer customers on social platforms by gathering information, developing specialized content, and conducting targeted interactions with customers, malicious actors can similarly use these platform attributes to target high value employees with a deeper level of engagement.  

Additionally, individual employees engage with social networks in a capacity that straddles both their professional and personal lives. While enterprises assert security controls over corporate-issued devices and place restrictions on how consumer devices access corporate IT assets, user activity on social network platforms is not monitored or controlled in the same way. As mentioned, LinkedIn and Twitter direct messaging will not be the only vectors of concern for the corporate security operations center (SOC). 

While it is unlikely that email will ever be replaced as an attack vector, McAfee foresees this social network platform vector becoming more common in 2021 and beyond, particularly among the most advanced actors. 

The post 2021 Threat Predictions Report appeared first on McAfee Blogs.

A Year in Review: Threat Landscape for 2020

As we gratefully move forward into the year 2021, we have to recognise that 2020 was as tumultuous in the digital realm as it has in the physical world. From low level fraudsters leveraging the pandemic as a vehicle to trick victims into parting with money for non-existent PPE, to more capable actors using malware that has considerably less prevalence in targeted campaigns. All of which has been played out at a time of immense personal and professional difficulties for millions of us across the world.

Dealing with the noise

What started as a trickle of phishing campaigns and the occasional malicious app quickly turned to thousands of malicious URLs and more-than-capable threat actors leveraging our thirst for more information as an entry mechanism into systems across the world. There is no question that COVID was the dominant theme of threats for the year, and whilst the natural inclination will be to focus entirely on such threats it is important to recognise that there were also very capable actors operating during this time.

For the first time we made available a COVID-19 dashboard to complement our threat report to track the number of malicious files leveraging COVID as a potential lure.  What this allows is real time information on the prevalence of such campaigns, but also clarity about the most targeted sectors and geographies.  Looking at the statistics from the year clearly demonstrates that the overarching theme is that the volume of malicious content increased.

Whilst of course this a major concern, we must recognise that there were also more capable threat actors operating during this time.

Ransomware – A boom time

The latter part of 2020 saw headlines about increasing ransom demands and continued successes from ransomware groups. An indication as to the reason why was provided in early 2020 in a blog published by Thomas Roccia that revealed “The number of RDP ports exposed to the Internet has grown quickly, from roughly three million in January 2020 to more than four and a half million in March.”

With RDP a common entry vector used predominantly by post intrusion ransomware gangs, there appears some explanation as to the reason why we are seeing more victims in the latter part of 2020.   Indeed, in the same analysis from Thomas we find that the most common passwords deployed for RDP are hardly what we would regard as strong.

If we consider the broader landscape of RDP being more prevalent (we have to assume due to the immediate need for remote access due to the lockdowns across the globe), the use of weak credentials, then the success of ransomware groups become very evident.  Indeed, later in the year we detailed our research into the Netwalker ransomware group that reveals the innovation, affiliate recruitment and ultimately financial success they were able to gain during the second quarter of 2020.

A year of major vulnerabilities

The year also provided us with the added gifts of major vulnerabilities. In August, for example, there was a series of zero-day vulnerabilities in a widely used, low-level TCP/IP software library developed by Treck, Inc.  Known as Ripple 20, the affect to hundreds of millions of devices resulted in considerable concern related to the wider supply chain of devices that we depend upon. In collaboration with JSOF, the McAfee ATR team developed a Detection Logic and Signatures for organizations to detect these vulnerabilities.

Of course the big vulnerabilities did not end there; we had the pleasure of meeting BadNeighbour, Drovorub, and so many more. The almost seemingly endless stream of vulnerabilities with particularly high CVSS Scores has meant that the need to patch very high on the list of priorities.

The ‘sophisticated’ attacker

As we closed out 2020, we were presented with details of ‘nation states’ carrying out sophisticated attacks.   Whilst under normal circumstances such terminology is something that should be avoided, there is no question that the level of capability we witness from certain threat campaigns are a world away from the noisy COVID phishing scams.

In August of 2020, we released the MVISION Insights dashboard which provides a free top list of campaigns each week. This includes, most recently, tracking against the SUNBURST trojan detailed in the SolarWinds attack, or the tools stolen in the FireEye breach.   What this demonstrates is that whilst prevalence is a key talking point, there exists capable threat actors targeting organizations with real precision.

For example, the Operation North Star campaign in which the threat actors deployed an Allow and Block list of targets in order to limit those they would infect with a secondary implant.

The term sophisticated is overused, and attribution is often too quickly relegated to the category of nation state.  However, the revelations have demonstrated that there are those campaigns where the attack did use capabilities not altogether common and we are no doubt witnessing a level of innovation from threat groups that is making the challenge of defence harder.

What is clear is that 2020 was a challenging year, but as we try and conclude what 2021 has in store, we have to celebrate the good news stories.   From initiatives such as No More Ransom continuing to tackle ransomware, to the unprecedented accessibility of tools that we can all use to protect ourselves (e.g. please check ATR GitHub repo, but recognise there are more).

McAfee 2021 Threat Predictions

Our experts share their 2021 predictions for the new year and how to protect yourself and your enterprise.

Read Now

The post A Year in Review: Threat Landscape for 2020 appeared first on McAfee Blogs.

Honoring Martin Luther King Jr.’s Legacy with McAfee’s African Heritage Community

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 Manager

For 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 Manager

MLK 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.

Learn More About Dr. King’s Mark on the World 

About The King Center 

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.

Two Pink Lines

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 A-B -C ‘s

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.

Peek-A-Boo

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.

• Where is the recorded video and audio data being stored? This may not seem important if the device is internet connected anyway, but it can be.  If your camera data is being stored locally (DVR, SD card, network storage, etc.), then an attacker would need to hack your specific device to obtain this information.   If you combine this with good security hygiene such as a strong password and keeping your device updated, an attacker has to work very hard to access your camera data.  If we look at the alternative where your footage is stored in the cloud, and it becomes subject to a security breach, now your camera’s video content is collateral damage.  Large corporations are specifically targeted by cybercriminals because they provide a high ROI for the time spent on the attack; an individual practicing good cybersecurity hygiene becomes a much more difficult target providing less incentive for the attacker, thus becoming a less likely target.
• Is the camera on the same network as the rest of your home? An often-overlooked security implication to many IoT devices, but especially cameras, is outside of the threat of spying, but rather the threat of a network entry point. If the camera itself is compromised it can be used as a pivot point to attack other devices on your network.  A simple way to reduce this risk is to utilize the “guest” network feature that comes by default on almost all home routers.   These guest networks are preset to be isolated from your main network and generally require little to no setup.  By simply attaching your cameras to your guest network, you can reduce the risk of a compromised camera leading a cybercriminal to the banking info on your laptop.

Background checks – Not only for babysitters

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:

• Was the vulnerability quickly patched?
• Are there unpatched bugs still?
• Has a vendor self-reported flaws, fixed them and reported to the public they have been fixed?
• Are there numerous outstanding bugs filed against a company or device?
• Does the company not recognize the possibility of bugs in their products?

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.

Remember, you can do this!

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.

McAfee ATR Launches Education-Inspired Capture the Flag Contest!

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: 

• Choose the type of challenge you want to work on, 
• Select a difficulty level by point value, 
• Solve the challenge to find a ‘flag,’ and 
• Enter the flag for the corresponding points.​​​​​

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: 

• Reverse engineering 
• Exploitation 
• Web 
• Hacking Tools 
• Crypto 
• RF (Radio Frequency) 
• Mobile 
• Hardware
   

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.  

Read before hacking: CTF rules and guidelines 

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. 

Cooperation 

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! 

Attacking the Platform 

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. 

Sabotage 

Absolutely no sabotaging of other competing teams, or in any way hindering their independent progress. 

Brute Forcing 

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. 

Denial–of–Service 

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! 

Looking for a little extra help? 

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. 

Contact Us 

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. 

ATR_CTF@McAfee.com 

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. 

General Release Statement 

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.

Researchers Follow the Breadcrumbs: The Latest Vulnerabilities in Windows’ Network Stack

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.

Don’t Call Us We’ll Call You: McAfee ATR Finds Vulnerability in Agora Video SDK

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.

To boldly go where no one has gone before

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.

What is Agora?

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.

“They’ve done studies, you know. 60% of the time, encrypting works every time.”

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.

The Spy Who Loved Me

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.

You talkin’ to me? Are you talkin’ to me?

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.

Yo, Adrian, we did it. We did it.

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.

Vulnerability Details

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.

Beyond Clubhouse: Vulnerable Agora SDKs Still in Widespread Use

On February 17^th, 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 17^th, 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 8^th, 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 16^th – 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:

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.

Babuk Ransomware

Executive Summary

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)

Coverage and Protection Advice

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:

• E-mail Spearphishing (T1566.001). Often used to directly engage and/or gain an initial foothold, the initial phishing email can also be linked to a different malware strain, which acts as a loader and entry point for the ransomware gangs to continue completely compromising a victim’s network. We have observed this in the past with Trickbot and Ryuk, Emotet and Prolock, etc.
• Exploit Public-Facing Application (T1190) is another common entry vector; cyber criminals are avid consumers of security news and are always on the lookout for a good exploit. We therefore encourage organizations to be fast and diligent when it comes to applying patches. There are numerous examples in the past where vulnerabilities concerning remote access software, webservers, network edge equipment and firewalls have been used as an entry point.
• Using valid accounts (T1078) is and has been a proven method for cybercriminals to gain a foothold. After all, why break the door if you have the keys? Weakly protected Remote Desktop Protocol (RDP) access is a prime example of this entry method. For the best tips on RDP security, we would like to highlight our blog explaining RDP security.
• Valid accounts can also be obtained via commodity malware such as infostealers, that are designed to steal credentials from a victim’s computer. Infostealer logs containing thousands of credentials are purchased by ransomware criminals to search for VPN and corporate logins. As an organization, robust credential management and multi-factor authentication on user accounts is an absolute must have.

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.

Summary of the Threat

• Babuk ransomware is a new ransomware family originally detected at the beginning of 2021.
• Its operators adopted the same operating methods as other ransomware families and leaked the stolen data on a public website: hxxp://gtmx56k4hutn3ikv.onion/.
• Babuk’s codebase and artefacts are highly similar to Vasa Locker’s.
• Babuk advertises on both English-speaking and Russian-speaking forums, where it seems the former is used for announcements and the latter is focused on affiliate recruitment and ransomware updates.
• The individuals behind Babuk ransomware have explicitly expressed themselves negatively against the BlackLivesMatter (BLM) and LGBT communities.
• At least 5 companies have been breached as of January 15, 2021.
• The ransomware supports command line operation and embeds three different built-in commands used to spread itself and encrypt network resources.
• It checks the services and processes running so it can kill a predefined list and avoid detection.
• There are no local language checks, in contrast to other ransomware gangs that normally spare devices in certain countries.
• The most recent variant has been spotted packed.

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.

Babuk Ransomware

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.

McAfee ATR Thinks in Graphs

0. Introduction

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.

Section 1. Dataset

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.

Section 2. Research Goal

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:

Frequency

• Which techniques are observed most often?
• Which actors are the most active?

Popularity

• Which techniques are the most common across actors?

Patterns

• Can we identify groups of actors using the same techniques?
• Are actors using techniques in the same way?

These questions are not exhaustive of everything that can be achieved using this methodology, but they reveal an example of what is possible.

Section 3. Methodology

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.

Section 4. Dataset Validation

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.

Section 5. Building Graphs

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.

Section 5.1 Event-centric View

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.

Section 5.2 Actor-centric View

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.

Section 6. Using the Graphs

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.

Section 6.1 Frequency Analysis

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.

Section 6.2 Popularity Analysis

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.

6.3 Patterns Identification

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:

1. A lot of actors use the same techniques.
2. We need to introduce additional information if we want to dismember the dense bundle of nodes.

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.

Section 7. Introducing Killchain Information

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.

Section 8. Limitations

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.

Section 9. Conclusion

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.”

Section 10. Future Work

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.

How McAfee’s Inclusive Maternity Benefits Helped Me Thrive as a New Mom

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.

Joining McAfee

My journey at McAfee began in 2017 as a People Partner. My role includes developing policies and processes for People Success. 

Welcoming My Daughter

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. 

Finding Balance with the Help of McAfee’s Benefits 

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. 

Opting for Gradual Return to Work with McAfee

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.

Reuniting with Team Members

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.

Life Mantra

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.

Shiva’s Tragic Accident Turns into a Story of Resilience

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:

A Tragic Accident

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.

Financial Challenges

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.    

 
The Road to Recovery 

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. 

Team Support

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.

Returning to the Workplace

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. 

Joining McAbility

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.

Continuing Life

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.

Life Mantra

“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.

How a Group of McAfee Team Members Helped Change the Lives of Critically Ill Children

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.

Seven Windows Wonders – Critical Vulnerabilities in DNS Dynamic Updates

Overview

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.

DNS Dynamic Updates, Threats and Deployment

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).

Attack Pre-requisites

• AD Integrated DNS Dynamic Updates (default config of secure updates)
  • A DNS server must accept write requests to at least one Zone (typically a primary DNS server only allows Zone RR writes but there are misconfigurations and secondary servers which can negate this)
  • Domain-joined machine
  • Attacker must craft request to DNS server and supply a target Zone in request
• Standalone DNS Server (secure/nonsecure config)
  • A DNS server must accept write requests to at least one Zone (typically a primary DNS server only allows Zone RR writes but there are misconfigurations and secondary servers which can negate this) 
  • Attacker must craft request to DNS server and supply a target Zone in request 

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.

Vulnerability Analysis

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.

Analysis of CVE-2021-26877

• The vulnerability is triggered when a Zone is updated with a TXT RR that has a “TXT length” greater than “Data length” per Wireshark below:

Figure 1: Wireshark view of exploit packet classifying the DNS packet as malformed

• The vulnerability is in the File_PlaceStringInFileBuffer() function as you can see from WinDbg output below:

Figure 2: WinDbg output of crash while attached to dns.exe

• The vulnerability is an Out of bounds (OOB) read on the heap when the “TXT length” field of DNS Dynamic Zone Update is not validated relative to “Data length”. This could allow an attacker to read up to 255 bytes of memory. Microsoft states this vulnerability can be used to achieve RCE; this would require a further OOB write primitive.
• The memory allocation related to the OOB read is created within the CopyWireRead() function. Relevant pseudo code for this function is below:

• The 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.

Analysis of CVE-2021-26897

• The vulnerability is triggered when many consecutive Signature RRs Dynamic Updates are sent
• The vulnerability is an OOB write on the heap when combining the many consecutive Signature RR Dynamic Updates into base64-encoded strings before writing to the Zone file
• Microsoft states this vulnerability can be used to achieve RCE

Figure 3: Packet containing many consecutive Signature RR dynamic updates. Pay special attention to the length field of the reassembled flow.

Exploitability

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

Mitigations

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:

1. DNS Primary Server should restrict clients that can update RRs
2. Secure Dynamic Update using GSS-TSIG
3. Secondary DNS Server Dynamic Update forwarding restrictions using GSS-TSIG
4. Fine-grained Dynamic Update restrictions using GSS-TSIG

The post Seven Windows Wonders – Critical Vulnerabilities in DNS Dynamic Updates appeared first on McAfee Blogs.

McAfee Defender’s Blog: Operation Dianxun

Operation Dianxun Overview

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.

Defensive Architecture Overview

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.

Investigation and Threat Hunting with MVISION EDR

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.

Summary

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.

Operation Diànxùn: Cyberespionage Campaign Targeting Telecommunication Companies

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.

Coverage and Protection

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. 

Summary of the Threat

We assess with a high level of confidence that:

• Recent attacks using TTPs similar to those of the Chinese groups RedDelta and Mustang Panda have been discovered.
• Multiple overlaps including tooling, network and operating methods suggest strong similarities between Chinese groups RedDelta and Mustang Panda.
• The targets are mainly telecommunication companies based in Southeast Asia, Europe, and the US. We also identified a strong interest in German and Vietnamese telecommunication companies.

We assess with a moderate level of confidence that:

• We believe that this espionage campaign is aimed at stealing sensitive or secret information in relation to 5G technology.

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.

Netop Vision Pro – Distance Learning Software is 20/20 in Hindsight

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.

Initial Recon

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

Fuzzing the Broadcast Messages

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

Reversing the Network Protocol

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.

Replaying a Command Action

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:

• Remote CMD execution
• Screen blank the student
• Restart Netop
• Shutdown the computer
• Block web access to individual websites
• Unlock the Netop properties (on student computer)

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.

Exploring Plugins

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

Reversing MChat Network Traffic

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.

Impact

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.

Disclosure and Recommended Mitigations

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.

McAfee Defenders Blog: Reality Check for your Defenses

Welcome to reality

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:

1. How is malware defined? Are we focusing solely on Viruses and Trojans, or do we also include Adware and others?
2. What malware types are currently spread across the globe? What died of old age and what is brand new?
3. How does malware operate? Is file-less malware a short-lived trend or is it here to stay?
4. What needs to be done to adequately defend against malware? What capabilities are needed?
5. What defenses are already in place? Are they configured correctly?

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!

A quick glance into the past

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:

How a new McAfee solution changed my perception, all while becoming a constant pun

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:

1. I can never use the word “insights” anymore as everyone would think I use it as a pun
2. MVISION Insights presented me with verified data of current campaigns running around in the wild
3. MVISION Insights also aligns the description of threats to the MITRE ATT&CK® Framework, making them comparable
4. From the ATT&CK Framework I could also link from the threat to defensive capabilities

With 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:

1. Initial Access comes from either having already access to a system or by sending out spear phishing attachments
2. Execution uses various techniques from CLI, to PowerShell and WMI
3. Files and network shares are being discovered so the ransomware knows what to encrypt
4. Command and control techniques need to be in place to communicate with the ransomware service provider
5. Files are encrypted on impact, which is kind of a no-brainer, but on the other hand very sound-proof on what we feel what ransomware is doing, and it is underlined by the work of the threat researchers and the resulting data

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:

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:

1. Execution, persistence, and defense evasion are tactics where a lot of capabilities are present, because we have a lot of mature security controls to control what is being executed, in what context and especially defense evasion techniques are good to detect and protect against.
2. Discovery has no real protection capability mapped to it, as tools might give you indicators that something suspicious is happening but blocking every potential file discovery activity will have a very huge operational impact. However, you can use sandboxing or other techniques to assess what the ransomware is doing and use the result from this analysis to stop ongoing malicious processes.
3. Impact has a similar story, as you cannot block any process that encrypts a file, as there are many legitimate reasons to do so and hundreds of ways to accomplish this task. But again, you can monitor these actions well and with the right technology in place, even roll back the damage that has been done.

Now with all this data at hand we can come to the final step and bring it all together in one simple graph.

One graph to bind them…

Before we jump into our conclusion, here is a quick summary of the actions I have taken:

1. Gather data from 60 ransomware campaigns
2. Pull out the MITRE ATT&CK techniques being used
3. Map the necessary security capabilities to these techniques
4. Bucketize the capabilities depending on where they are in the threat defense lifecycle
5. Map McAfee solutions to the capabilities and applying a weight to the score
6. Calculate the score for each solution
7. Create graph for the ransomware detection & protection score for our most common endpoint bundles and design the best fitting security architecture

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 3^rd-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:

1. It all starts with the technology on the endpoint. A good Endpoint Protection Platform can not only prevent attacks and harden the system, but it can also protect against threats when they are written on a disk or are executed, and then start malicious activities. But what is commonly overlooked: A good endpoint solution can also bring in a lot of visibility, making it the foundation of every good incident response practice.
2. ATD plays a huge role in the overall architecture as you can see from the increase in points between MVISION Premium and MVISION Premium + ATD in the graph above. It allows the endpoint to have another opinion, which is not limited in time and resources to come to a conclusion, and it has no scan exceptions applied when checking a file. As this is integrated into the protection, it helps block threats before spreading and it certainly provides tremendous details around the malware that was discovered.
3. MVISION Insights also plays a huge role in both preventative actions, so that you can harden your machines before you are hit, but also in detecting things that might have slipped through the cracks or where new indicators have emerged only after a certain time period.
4. MVISION EDR has less impact on the scoring, as it is a pure detection technology. However, it also has a similar advantage as our McAfee ATD, as the client only forwards the data, and the heavy lifting is done somewhere else. It also goes back around, as EDR can pull in data from other tools shown above, like ENS, TIE or ATD just to name a few.
5. MVISION ePO must be present in any McAfee architecture, as it is the heart and soul for every operational task. From managing policies, rollouts, client-tasks, reporting and much more, it plays a critical role and has for more than two decades now.

And the answer is not 42

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:

1. How is malware defined? Are we focusing solely on Viruses and Trojans, or do we also include Adware and others?
2. What malware types are currently spread across the globe? What died of old age and what is brand new?
3. How does malware operate? Is file-less malware a short-lived trend or is it here to stay?
4. What needs to be done to adequately defend against malware? What capabilities are needed?
5. What defenses are already in place? Are they configured correctly?

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:

• Do you have the right capabilities to protect against the techniques used by current ransomware campaigns?
• Is detection already a key part of your environment and how does it help to improve your protection?
• Have you recently tested your defenses against a common threat campaign?
• Are you sharing detections within your architecture from one security tool to the other?
• What score would your environment reach?

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.

McAfee Defender’s Blog: Cuba Ransomware Campaign

Cuba Ransomware Overview

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.

Gathering Intelligence on Cuba Ransomware

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.

Defensive Architecture Overview

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.

Initial Access Stage Defensive Overview

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.

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/

Exploitation Stage Defensive Overview

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.