Normal view

There are new articles available, click to refresh the page.
Before yesterdayMcAfee Blogs

A New Program for Your Peloton – Whether You Like It or Not

By: Sam Quinn
16 June 2021 at 04:01
Connected Fitness

Executive Summary 

The McAfee Advanced Threat Research team (ATR) is committed to uncovering security issues in both software and hardware to help developers provide safer products for businesses and consumers. As security researchers, something that we always try to establish before looking at a target is what our scope should be. More specifically, we often assume well-vetted technologies like network stacks or the OS layers are sound and instead focus our attention on the application layers or software that is specific to a target. Whether that approach is comprehensive sometimes doesn’t matter; and it’s what we decided to do for this project as well, bypassing the Android OS itself and with a focus on the Peloton code and implementations. During our research process, we uncovered a flaw (CVE-2021-33887) in the Android Verified Boot (AVB) process, which was initially out of scope, that left the Peloton vulnerable. 

For those that are not familiar with Peloton, it is a brand that has combined high end exercise equipment with cutting-edge technology. Its products are equipped with a large tablet that interfaces with the components of the fitness machine, as well as provides a way to attend virtual workout classes over the internet. “Under the hood” of this glossy exterior, however, is a standard Android tablet, and this hi-tech approach to exercise equipment has not gone unnoticed. Viral marketing mishaps aside, Peloton has garnered attention recently regarding concerns surrounding the privacy and security of its products. So, we decided to take a look for ourselves and purchased a Pelton Bike+.

Attempting to Backup 

One of the first things that we usually try do when starting a new project, especially when said projects involve large expenses like the Peloton, is to try to find a way to take a backup or system dump that could be used if a recovery is ever needed. Not all of our research techniques keep the device in a pristine state (we’d be poor hackers if they did)and having the ability to restore the device to its factory settings is a safety net that we try to implement on our targets 

Because we are working with a normal Android device with only the Peloton customizations running at the application layer, many of the processes used to back up an Android phone would also work with the Peloton. It is common in the Android custom ROM scene to use a custom recovery image that allows the user to take full flash dumps of each critical partition and provides a method to restore them later. In such communities, it often also goes without saying that the device must first be unlocked in order to perform any of these steps. While the Android OS allows users to flash these critical partitions, there are restrictions in place that typically prevent an attacker from gaining access to the “currently” running system. If an attacker was able to get their hands on an Android device with the goal of installing a rootkit, they would have to jump through some hoops. The first step that an attacker would need to take is to enable “Original Equipment Manufacturer (OEM) Unlocking”, which is a user mode setting within the “developer options” menu. Even with physical access to the bootloader, an attacker would not be able to “unlock” the Android device unless this setting is checked. This option is usually secured behind the user’s password, PIN, or biometric phone lock, preventing an attacker from accessing it easily. The second security measure in place is that even with the “OEM Unlocking” setting on, issuing commands to the bootloader to perform the unlock first causes all data on the Android device, including applications, files, passwords, etc., to be wiped. This way, even if an attacker did gain access to the Android device of an unsuspecting victim, they wouldn’t be able to install a rootkit or modify the existing kernel without deleting all the data, which both prevents personal data from falling into the attacker’s hands and makes it obvious the device has been tampered with. 

For this research effort, wresisted the urge to unlock the Peloton, as there are ways for apps to query the unlock status of a device within Android, and we wanted to ensure that any vulnerabilities we found weren’t the result of the device behaving differently due to it being unlocked. These discrepancies that arise from our research are usually identified by having two target devices: one to serve as the control and the other to serve as the test device. Unfortunately, we only had one Peloton to play with. Another issue was that the Peloton hardware is not very common and the developers of the aforementioned custom recovery images, like Team Win Recovery Project (TWRP), don’t create images for every device,  just the most common ones. So, the easy method of taking a backup would not only require unlocking the device but also trying to create our own custom recovery image 

This left us as at a crossroads. We could unlock the bootloader and root the device, granting us access to the flash memory block devices (raw interfaces to the flash partitions) internallywhich would allow us to create and restore backups as needed. However, as mentioned before, this would leave the bike in a recognizably “tampered” state. Alternatively, we could try to capture one of the bike’s Over-The-Air (OTA) updates to use as backup, but we would still need to “unlock” the device to actually flash the OTA image manually. Both options were less than ideal so we kept looking for other solutions. 

Android Verified Boot Process

Just as Secure Boot provides a security mechanism for properly booting the OS on Windows PCs, Android has implemented measures to control the boot process, called Android Verified Boot (AVB). According to Android’s documentation, AVB requires cryptographically verifying all executable code and data that is part of the Android version being booted before it is used. This includes the kernel (loaded from the boot partition), the device tree (loaded from the dtbo partition), system partition, vendor partition, and so on. 

The Peloton Bike+ ships with the default settings of “Verity Mode” set to trueas well as “Device Unlocked” and “Device Critical Unlocked” set to falsewhich is intended to prevent the loading of modified boot images and provide a way to determine if the device has been tampered with. This information was verified by running fastboot oem device-info on the Peloton, as demonstrated in Figure 1. 

 

Figure 1: OEM device info showing verity mode and unlocked status. 

To clarify, a simplified Android boot process can be visualized as follows: 


Figure 2: Simplified Android Boot Process 

If modified code is found at any of the stages in Figure 2, the boot process should abort or, if the device is unlocked, warn the user that the images are not verified and give the option to the user to abort the boot. 

Given that we defined our scope of this project to not include the Android boot process as a part of our research and verifying that Peloton has attempted to use the security measures provided by Android, we again found ourselves debating if a backup would be possible.  

In newer Android releases, including the Peloton, the update method uses Android’s Seamless System Updates (A/B). This update method no longer needs the “recovery” partition, forcing users who wish to use a custom recovery to use the fastboot boot command which will download and boot the supplied image. This is a temporary boot that doesn’t “flash“ or alter any of the flash partitions of the device and will revert to the previous boot image on restartSince this option allows for modified code to be executed, it is only available when the device is in an unlocked state and will error out with a message stating Please unlock device to enable this command, if attempted on a locked device.  

This is a good security implementation because if this command was always allowed, it would be very similar to the process of booting from a live USB on your PC, where you can login as a root user and have full control over the underlying system and components. 

Booting Modified Code 

This is where our luck or maybe naïveté worked to our advantage. Driven by our reluctance to unlock the device and our desire to make a backup, we tried to boot a generic TWRP recovery image just to see what would happen. The image ended up leaving us at a black screen, and since each recovery image needs to contain a small kernel with the correct drivers for the display, touch digitizer, and other devicespecific hardware, this was to be expectedWhat we didn’t expect, however, was for it to get past the fastboot boot command. While we didn’t get a custom recovery running, it did tell us one thingthe system was not verifying that the device was unlocked before attempting to boot a custom imageNormally this command would be denied on a “locked” device and would have just errored out on the fastboot command, as mentioned previously. 

It is also important to point out that despite having booted a modified image, the internal fuse had not been burned. These fuses are usually burned during the OEM unlocking process to identify if a device has allowed for a different “root of trust” to be installed. The burning of such a fuse is a permanent operation and a burnt fuse often indicates that the device has been tampered with. As shown in Figure 3, the “Secure Boot” fuse was still present, and the device was reporting a locked bootloader. 

Figure 3: Secure boot enabled with fused protection 

Acquiring an OTA Image 

This discovery was unexpected and we felt like we had stumbled upon a flaw that gave us the ability to finally take a backup of the device and leave the Peloton in an “untampered” state. Knowing that a custom image could be booted even with a “locked” bootloader, we began looking at ways to gather a valid boot image, which would contain the correct kernel drivers to facilitate a successful boot. If we could piece together the OTA update URL and just download an update package directly from Peloton, it would likely contain a boot image that we could modifyHaving the ability to modify a boot image would give us root and access to the blocked devices. 

Even with just ADB debugging enabled we were able to pull the Pelotonspecific applications from the device. We listed all the Peloton APKand sought out the ones that could help us get the OTA path, shown in Figure 4. 

Figure 4: Listing Peloton Specific Applications and Highlighting the one related to OTA Updates. 

Finding the name OTAService promising, we pulled down the APK and began to reverse-engineer it using JADX. After some digging, we discovered how the app was building the download URL string for OTA updateswhich would then be passed to beginDownload(), as seen in Figure 5. 

Figure 5OTA image path being constructed as “key” 

We also noticed quite a few Android log calls that could help us, such as the one right before the call to beginDownload(), so we used Android’s builtin logcat command and grepped the output for “OTA” as seen in Figure 6. Doing so, we were able to find which S3 bucket was used for the OTA updates and even a file manifest titled OTAConfig.json  

Figure 6: Relevant OTA logs in red 

Combining the information obtained from OTAService.apk and the logs, we were able to piece together the full path to the OTA images manifest file and names for each OTA zip file, as shown in Figure 7.  

Figure 7: Contents of OTAConfig.json 

Our next step was to extract the contents of the OTA update to get a valid boot.img file that would contain all the specific kernel drivers for the Peloton hardware. Since the Peloton is using AndroidA/B partitions, which facilitate seamless updates, the update packages were stored in a “payload.bin” format. Using the Android payload dumper tool, we were able to extract all of the images contained in the bin file. 

Modifying the Boot Image 

Once the boot.img was extracted, we needed a way to modify the initial kernel to allow us to gain root access on the device. Although there are a variety of ways to accomplish this, we decided to keep things simple and just use the Magisk installer to patch the boot.img file to include the “su” binary. With the boot.img patched, we were able to use the fastboot boot command again but this time passing it our patched boot.img file. Since the Verified Boot process on the Peloton failed to identify the modified boot image as tampered, the OS booted normally with the patched boot.img file. After this process was complete, the Peloton Bike+ was indistinguishable from its “normal” state under visual inspection and the process left no artifacts that would tip off the user that the Pelton had been compromised. But appearances can be deceiving, and in reality the Android OS had now been rootedallowing us to use the su” command to become root and perform actions with UID=0, as seen in Figure 8. 

Figure 8: Booting modified boot.img and executing whoami as Root 

Impact Scenarios 

As we just demonstrated, the ability to bypass the Android Verified Boot process can lead to the Android OS being compromised by an attacker with physical accessA worst-case scenario for such an attack vector might involve a malicious agent booting the Peloton with a modified image to gain elevated privileges and then leveraging those privileges to establish a reverse shell, granting the attacker unfettered root access on the bike remotely. Since the attacker never has to unlock the device to boot a modified image, there would be no trace of any access they achieved on the device. This sort of attack could be effectively delivered via the supply chain process. A malicious actor could tamper with the product at any point from construction to warehouse to delivery, installing a backdoor into the Android tablet without any way the end user could know. Another scenario could be that an attacker could simply walk up to one of these devices that is installed in a gym or a fitness room and perform the same attack, gaining root access on these devices for later use. The Pelobuddy interactive map in figure 9 below could help an attacker find public bikes to attack. 

Figure 9pelobuddy.com’s interactive map to help locate public Peloton exercise equipment. 

Once an attacker has root, they could make their presence permanent by modifying the OS in a rootkit fashion, removing any need for the attacker to repeat this step. Another risk is that an attacker could modify the system to put themselves in a man-in-the-middle position and sniff all network traffic, even SSL encrypted traffic, using a technique called SSL unpinning, which requires root privileges to hook calls to internal encryption functionality. Intercepting and decrypting network traffic in this fashion could lead to users personal data being compromised. Lastly, the Peloton Bike+ also has a camera and a microphone installed. Having remote access with root permissions on the Android tablet would allow an attacker to monitor these devices and is demoed in the impact video below. 

Disclosure Timeline and Patch 

Given the simplicity and criticality of the flaw, we decided to disclose to Peloton even as we continue to audit the device for remote vulnerabilities. We sent our vendor disclosure with full details on March 2, 2021 – shortly after, Peloton confirmed the issue and subsequently released a fix for it in software version “PTX14A-290”. The patched image no longer allows for the “boot” command to work on a user build, mitigating this vulnerability entirelyThe Peloton vulnerability disclosure process was smooth, and the team were receptive and responsive with all communications. Further conversations with Peloton confirmed that this vulnerability is also present on Peloton Tread exercise equipment; however, the scope of our research was confined to the Bike+.

Peloton’s Head of Global Information Security, Adrian Stone, shared the following “this vulnerability reported by McAfee would require direct, physical access to a Peloton Bike+ or Tread. Like with any connected device in the home, if an attacker is able to gain physical access to it, additional physical controls and safeguards become increasingly important. To keep our Members safe, we acted quickly and in coordination with McAfee. We pushed a mandatory update in early June and every device with the update installed is protected from this issue.”

We are continuing to investigate the Peloton Bike+, so make sure you stay up to date on McAfee’s ATR blogs for any future discoveries. 

The post A New Program for Your Peloton – Whether You Like It or Not appeared first on McAfee Blog.

Are Virtual Machines the New Gold for Cyber Criminals?

AI Cyber Security

Introduction

Virtualization technology has been an IT cornerstone for organization for years now. It revolutionized the way organizations can scale up IT systems in a heartbeat, allowing then to be more agile as opposed to investing into dedicated “bare-metal” hardware. To the outside untrained eye, it might seem that there are different machines on the network, while in fact all the “separate” machines are controlled by a hypervisor server. Virtualization plays such a big role nowadays that it isn’t only used to spin up servers but also anything from virtual applications to virtual user desktops.

This is something cyber criminals have been noticing too and we have seen an increased interest in hypervisors. After all, why attack the single virtual machine when you can go after the hypervisor and control all the machines at once?

In recent months several high impact CVEs regarding virtualization software have been released which allowed for Remote Code Execution (RCE); initial access brokers are offering compromised VMware vCenter servers online, as well as ransomware groups developing specific ransomware binaries for encrypting ESXi servers.

VMware CVE-2021-21985 & CVE-2021-21986

On the 25th of May VMware disclosed a vulnerability impacting VMware vCenter servers allowing for Remote Code Execution on internet accessible vCenter servers, version 6.5,6.7 and 7.0. VMware vCenter is a management tool, used to manage virtual machines and ESXi servers.

CVE-2021-21985 is a remote code execution (RCE) vulnerability in the vSphere Client via the Virtual SAN (vSAN) Health Check plugin. This plugin is enabled by default. The combination of RCE and default enablement of the plugin resulted in this being scored as a critical flaw with a CVSSv3 score of 9.8.

An attacker needs to be able to access vCenter over TCP port 443 to exploit this vulnerability. It doesn’t matter if the vCenter is remotely exposed or when the attacker has internal access.

The same exploit vector is applicable for CVE-2021-21986, which is an authentication mechanism issue in several vCenter Server Plug-ins. It would allow an attacker to run plugin functions without authentication. This leads to the CVE being scored as a ‘moderate severity’, with a CVSSv3 score of 6.5.

While writing this blog, a Proof-of-Concept was discovered that will test if the vulnerability exists; it will not execute the remote-code. The Nmap plugin can be downloaded from this location: https://github.com/alt3kx/CVE-2021-21985_PoC.

Searching with the Shodan search engine, narrowing it down to the TCP 443 port, we observe that close to 82,000 internet accessible ESXi servers are exposedZooming in further on the versions that are affected by these vulnerabilities,  almost 55,000 publicly accessible ESXi servers are potentially vulnerable to CVE-2021-21985 and CVE-2021-21986, providing remote access to them and making them potential candidates for ransomware attacks, as we will read about in the next paragraphs.

Ransomware Actors Going After Virtual Environments

Ransomware groups are always trying to find ways to hit their victims where it hurts. So, it is only logical that they are adapting to attacking virtualization environments and the native Unix/Linux machines running the hypervisors. In the past, ransomware groups were quick to abuse earlier CVEs affecting VMware. But aside from the disclosed CVEs, ransomware groups have also adapted their binaries specifically to encrypt virtual machines and their management environment. Below are some of the ransomware groups we have observed.

DarkSide Ransomware

Figure 1. Screenshot from the DarkSide ransomware group, explicitly mentioning its Linux-based encryptor and support for ESXi and NAS systems

McAfee Advanced Threat Research (ATR) analyzed the DarkSide Linux binary in our recent blog and we can confirm that a specific routine aimed at virtual machines is present in it.

Figure 2. DarkSide VMware Code routine

From the configuration file of the DarkSide Linux variant, it becomes clear that this variant is solely designed to encrypt virtual machines hosted on an ESXi server. It searches for the disk-files of the VMs, the memory files of the VMs (vmem), swap, logs, etc. – all files that are needed to start a VMware virtual machine.

Demo of Darkside encrypting an ESXi server: https://youtu.be/SMWIckvLMoE

Babuk Ransomware

Babuk announced on an underground forum that it was developing a cross-platform binary aimed at Linux/UNIX and ESXi or VMware systems:

Figure 3. Babuk ransomware claiming to have built a Linux-based ransomware binary capable of encrypting ESXi servers

The malware is written in the open-source programming language Golang, most likely because it allows developers to have a single codebase to be compiled into all major operating systems. This means that, thanks to static linking, code written in Golang on a Linux system can run on a Windows or Mac system. That presents a large advantage to ransomware gangs looking to encrypt a whole infrastructure comprised of different systems architecture.

After being dropped on the ESXi server, the malware encrypts all the files on the system:

The malware was designed to target ESXi environments as we guessed, and it was confirmed when the Babuk team returned the decryptor named d_esxi.out. Unfortunately, the decryptor has been developed with some errors, which cause corruption in victim’s files:

Overall, the decryptor is poor as it only checks for the extension “.babyk” which will miss any files the victim has renamed to recover them. Also, the decryptor checks if the file is more than 32 bytes in length as the last 32 bytes are the key that will be calculated later with other hardcoded values to get the final key. This is bad design as those 32 bytes could be trash, instead of the key, as the customer could make things, etc. It does not operate efficiently by checking the paths that are checked in the malware, instead it analyzes everything. Another error we noticed was that the decryptor tries to remove a ransom note name that is NOT the same that the malware creates in each folder. This does not make any sense unless, perhaps, the Babuk developers/operators are delivering a decryptor that works for a different version and/or sample.

The problems with the Babuk decryptor left victims in horrible situations with permanently damaged data. The probability of getting a faulty decryptor isn’t persuading victims to pay up and this might be one of the main reasons that Babuk  announced that it will stop encrypting data and only exfiltrate and extort from now on.

Initial-Access-Brokers Offering VMware vCenter Machines

It is not only ransomware groups that show an interest in virtual systems; several initial access brokers are also trading access to compromised vCenter/ESXi servers on underground cybercriminal forums. The date and time of the specific offering below overlaps with the disclosure of CVE-2021-21985, but McAfee ATR hasn’t determined if this specific CVE was used to gain access to ESXi servers.

Figure 4. Threat Actor selling access to thousands of vCenter/ESXi servers

Figure 5. Threat actor offering compromised VMware ESXi servers

Patching and Detection Advice

VMware urges users running VMware vCenter and VMware Cloud Foundation affected by CVE-2021-21985 and CVE-2021-21986 to apply its patch immediately. According to VMware, a malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server. The disclosed vulnerabilities have a critical CVSS base score of 9.8.

However, we do understand that VMware infrastructure is often installed on business-critical systems, so any type of patching activity usually has a high degree of impact on IT operations. Hence, the gap between vulnerability disclosure and patching is typically high. With the operating systems on VMware being a closed system they lack the ability to natively install workload protection/detection solutions. Therefore, the defenses should be based on standard cyber hygiene/risk mitigation practices and should be applied in the following order where possible.

  1. Ensure an accurate inventory of vCenter assets and their corresponding software versions.
  2. Secure the management plane of the vCenter infrastructure by applying strict network access control policies to allow access only from special management networks.
  3. Disable all internet access to vCenter/VMware Infrastructure.
  4. Apply the released VMware patches.
  5. McAfee Network Security Platform (NSP) offers signature sets for detection of CVE-2021-21985 and CVE-2021-21986.

Conclusion

Virtualization and its underlying technologies are key in today’s infrastructures. With the release of recently discovered vulnerabilities and an understanding of their criticality, threat actors are shifting focus. Proof can be seen in underground forums where affiliates recruit pentesters with knowledge of specific virtual technologies to develop custom ransomware that is designed to cripple these technologies. Remote Desktop access is the number one access vector in many ransomware cases, followed by edge-devices lacking the latest security updates, making them vulnerable to exploitation. With the latest VMware CVEs mentioned in this blog, we urge you to take the right steps to secure not only internet exposed systems, but also internal systems, to minimize the risk of your organization losing its precious VMs, or gold, to cyber criminals.

 

Special thanks to Thibault Seret, Mo Cashman, Roy Arnab and Christiaan Beek for their contributions.

The post Are Virtual Machines the New Gold for Cyber Criminals? appeared first on McAfee Blog.

Scammers Impersonating Windows Defender to Push Malicious Windows Apps

17 May 2021 at 21:25

Summary points:

  • Scammers are increasingly using Windows Push Notifications to impersonate legitimate alerts
  • Recent campaigns pose as a Windows Defender Update
  • Victims end up allowing the installation of a malicious Windows Application that targets user and system information

Browser push notifications can highly resemble Windows system notifications.  As recently discussed, scammers are abusing push notifications to trick users into taking action.  This recent example demonstrates the social engineering tactics used to trick users into installing a fake Windows Defender update.  A toaster popup in the tray informs the user of a Windows Defender Update.

Clicking the message takes the user to a fake update website.

The site serves a signed ms-appinstaller (MSIX) package.  When downloaded and run, the user is prompted to install a supposed Defender Update from “Publisher: Microsoft”

After installation, the “Defender Update” App appears in the start menu like other Windows Apps.

The shortcut points to the installed malware: C:\Program Files\WindowsApps\245d1cf3-25fc-4ce1-9a58-7cd13f94923a_1.0.0.0_neutral__7afzw0tp1da5e\bloom\Eversible.exe, which is a data stealing trojan, targeting various applications and information:

  • System information (Process list, Drive details, Serial number, RAM, Graphics card details)
  • Application profile data (Chrome, Exodus wallet, Ethereum wallet, Opera, Telegram Desktop)
  • User data (Credit card, FileZilla)

Am I protected?

  • McAfee customers utilizing Real Protect Cloud were proactively protected from this threat due to machine learning.
  • McAfee customers utilizing web protection (including McAfee Web Advisor and McAfee Web Control) are protected from known malicious sites.
  • McAfee Global Threat Intelligence (GTI) provides protection at Very Low sensitivity

General safety tips

  • See: How to Stop the Popups
  • Scams can be quite convincing. It’s better to be quick to block something and slow to allow than the opposite.
  • When in doubt, initiate the communication yourself.
    • For Windows Updates, click the Start Menu and type “Check For Updates”, click the System Settings link.
    • Manually enter in a web address rather than clicking a link sent to you.
    • Confirm numbers and addresses before reaching out, such as phone and email.

Reference IOCs

  • MSIX installer: 02262a420bf52a0a428a26d86aca177796f18d1913b834b0cbed19367985e190
  • exe: 0dd432078b93dfcea94bec8b7e6991bcc050e6307cd1cb593583e7b5a9a0f9dc
  • Installer source site: updatedefender [dot] online

 

The post Scammers Impersonating Windows Defender to Push Malicious Windows Apps appeared first on McAfee Blog.

DarkSide Ransomware Victims Sold Short

14 May 2021 at 10:32
How to check for viruses

Over the past week we have seen a considerable body of work focusing on DarkSide, the ransomware responsible for the recent gas pipeline shutdown. Many of the excellent technical write-ups will detail how it operates an affiliate model that supports others to be involved within the ransomware business model (in addition to the developers). While this may not be a new phenomenon, this model is actively deployed by many groups with great effect. Herein is the crux of the challenge: while the attention may be on DarkSide ransomware, the harsh reality is that equal concern should be placed at Ryuk, or REVIL, or Babuk, or Cuba, etc. These, and other groups and their affiliates, exploit common entry vectors and, in many cases, the tools we see being used to move within an environment are the same. While this technical paper covers DarkSide in more detail, we must stress the importance of implementing best practices in securing/monitoring your network. These additional publications can guide you in doing so:

DarkSide Ransomware:  What is it?

As mentioned earlier, DarkSide is a Ransomware-as-a-Service (RaaS) that offers high returns for penetration-testers that are willing to provide access to networks and distribute/execute the ransomware. DarkSide is an example of a RaaS whereby they actively invest in development of the code, affiliates, and new features. Alongside their threat to leak data, they have a separate option for recovery companies to negotiate, are willing to engage with the media, and are willing to carry out a Distributed Denial of Service (DDoS) attack against victims. Those victims who do pay a ransom receive an alert from DarkSide on companies that are on the stock exchange who are breached, in return for their payment. Potential legal issues abound, not to mention ethical concerns, but this information could certainly provide an advantage in short selling when the news breaks.

The group behind DarkSide are also particularly active. Using MVISION Insights we can identify the prevalence of targets. This map clearly illustrates that the most targeted geography is clearly the United States (at the time of writing). Further, the sectors primarily targeted are Legal Services, Wholesale, and Manufacturing, followed by the Oil, Gas and Chemical sectors.

Coverage and Protection Advice

McAfee’s market leading EPP solution covers DarkSide ransomware with an array of early prevention and detection techniques.

Customers using MVISION Insights will find a threat-profile on this ransomware family that is updated when new and relevant information becomes available.

Early Detection

MVISION EDR includes detections on many of the behaviors used in the attack including privilege escalation, malicious PowerShell and CobaltStrike beacons, and visibility of discovery commands, command and control, and other tactics along the attack chain. We have EDR telemetry indicating early detection before the detonation of the Ransomware payload.

Prevention

ENS TP provides coverage against known indicators in the latest signature set. Updates on new indicators are pushed through GTI.

ENS ATP provides behavioral content focusing on proactively detecting the threat while also delivering known IoCs for both online and offline detections.

ENS ATP adds two (2) additional layers of protection thanks to JTI rules that provide attack surface reduction for generic ransomware behaviors and RealProtect (static and dynamic) with ML models targeting ransomware threats.

For the latest mitigation guidance, please review:

https://kc.mcafee.com/corporate/index?page=content&id=KB93354&locale=en_US

Technical Analysis

The RaaS platform offers the affiliate the option to build either a Windows or Unix version of the ransomware. Depending on what is needed, we observe that affiliates are using different techniques to circumvent detection, by masquerading the generated Windows binaries of DarkSide. Using several packers or signing the binary with a certificate are some of the techniques used to do so.

As peers in our industry have described, we also observed campaigns where the affiliates and their hacking crew used several ways to gain initial access to their victim’s network.

  1. Using valid accounts, exploit vulnerabilities on servers or RDP for initial stage
  2. Next, establish a beachhead in the victim’s network by using tools like Cobalt-Strike (beacons), RealVNC, RDP ported over TOR, Putty, AnyDesk and TeamViewer. TeamViewer is what we also see back in the config of the ransomware sample:

The configuration of the ransomware contains several options to enable or disable system processes, but also the above part where it states which processes should not be killed.

As mentioned before, a lot of the current Windows samples in the wild are the 1.8 version of DarkSide, others are the 2.1.2.3 version. In a chat one of the actors revealed that a V3 version will be released soon.

On March 23rd, 2021, on XSS, one of the DarkSide spokespersons announced an update of DarkSide as a PowerShell version and a major upgrade of the Linux variant:

In the current samples we observe, we do see the PowerShell component that is used to delete the Volume Shadow copies, for example.

  1. Once a strong foothold has been established, several tools are used by the actors to gain more privileges.

Tools observed:

  • Mimikatz
  • Dumping LSASS
  • IE/FireFox password dumper
  • Powertool64
  • Empire
  • Bypassing UAC
  1. Once enough privileges are gained, it is time to map out the network and identify the most critical systems like servers, storage, and other critical assets. A selection of the below tools was observed to have been used in several cases:
  • BloodHound
  • ADFind
  • ADRecon
  • IP scan tools
  • Several Windows native tools
  • PowerShell scripts

Before distributing the ransomware around the network using tools like PsExec and PowerShell, data was exfiltrated to Cloud Services that would later be used on the DarkSide Leak page for extortion purposes. Zipping the data, using Rclone or WinSCP are some of the examples observed.

While a lot of good and in-depth analyses are written by our peers, one thing worth noting is that when running DarkSide, the encryption process is fast. It is one of the areas the actors brag about on the same forum and do a comparison to convince affiliates to join their program:

DarkSide, like Babuk ransomware, has a Linux version. Both target *nix systems but in particular VMWare ESXi servers and storage/NAS. Storage/NAS is critical for many companies, but how many of you are running a virtual desktop, hosted on a ESXi server?

Darkside wrote a Linux variant that supports the encryption of ESXI server versions 5.0 – 7.1 as well as NAS technology from Synology. They state that other NAS/backup technologies will be supported soon.

In the code we clearly observe this support:

Also, the configuration of the Linux version shows it is clearly looking for Virtual Disk/memory kind of files:

Although the adversary recently claimed to vote for targets, the attacks are ongoing with packed and signed samples observed as recently as today (May 12, 2021):

Conclusion

Recently the Ransomware Task Force, a partnership McAfee is proud to be a part of, released a detailed paper on how ransomware attacks are occurring and how countermeasures should be taken. As many of us have published, presented on, and released research upon, it is time to act. Please follow the links included within this blog to apply the broader advice about applying available protection and detection in your environment against such attacks.

MITRE ATT&CK Techniques Leveraged by DarkSide:

Data Encrypted for Impact – T1486

Inhibit System Recovery – T1490

Valid Accounts – T1078

PowerShell – T1059.001

Service Execution – T1569.002

Account Manipulation – T1098

Dynamic-link Library Injection – T1055.001

Account Discovery – T1087

Bypass User Access Control – T1548.002

File Permissions Modification – T1222

System Information Discovery – T1082

Process Discovery – T1057

Screen Capture – T1113

Compile After Delivery – T1027.004

Credentials in Registry – T1552.002

Obfuscated Files or Information – T1027

Shared Modules – T1129

Windows Management Instrumentation – T1047

Exploit Public-Facing Application – T1190

Phishing – T1566

External Remote Services – T1133

Multi-hop Proxy – T1090.003

Exploitation for Privilege Escalation – T1068

Application Layer Protocol – T1071

Bypass User Account Control – T1548.002

Commonly Used Port – T1043

Compile After Delivery – T1500

Credentials from Password Stores – T1555

Credentials from Web Browsers – T1555.003

Credentials in Registry – T1214

Deobfuscate/Decode Files or Information – T1140

Disable or Modify Tools – T1562.001

Domain Account – T1087.002

Domain Groups – T1069.002

Domain Trust Discovery – T1482

Exfiltration Over Alternative Protocol – T1048

Exfiltration to Cloud Storage – T1567.002

File and Directory Discovery – T1083

Gather Victim Network Information – T1590

Ingress Tool Transfer – T1105

Linux and Mac File and Directory Permissions Modification – T1222.002

Masquerading – T1036

Process Injection – T1055

Remote System Discovery – T1018

Scheduled Task/Job – T1053

Service Stop – T1489

System Network Configuration Discovery – T1016

System Services – T1569

Taint Shared Content – T1080

Unix Shell – T1059.004

The post DarkSide Ransomware Victims Sold Short appeared first on McAfee Blog.

Major HTTP Vulnerability in Windows Could Lead to Wormable Exploit

12 May 2021 at 15:48
AI Cyber Security

Today, Microsoft released a highly critical vulnerability (CVE-2021-31166) in its web server http.sys. This product is a Windows-only HTTP server which can be run standalone or in conjunction with IIS (Internet Information Services) and is used to broker internet traffic via HTTP network requests. The vulnerability is very similar to CVE-2015-1635, another Microsoft vulnerability in the HTTP network stack reported in 2015.

With a CVSS score of 9.8, the vulnerability announced has the potential to be both directly impactful and is also exceptionally simple to exploit, leading to a remote and unauthenticated denial-of-service (Blue Screen of Death) for affected products.

The issue is due to Windows improperly tracking pointers while processing objects in network packets containing HTTP requests. As HTTP.SYS is implemented as a kernel driver, exploitation of this bug will result in at least a Blue Screen of Death (BSoD), and in the worst-case scenario, remote code execution, which could be wormable. While this vulnerability is exceptional in terms of potential impact and ease of exploitation, it remains to be seen whether effective code execution will be achieved. Furthermore, this vulnerability only affects the latest versions of Windows 10 and Windows Server (2004 and 20H2), meaning that the exposure for internet-facing enterprise servers is fairly limited, as many of these systems run Long Term Servicing Channel (LTSC) versions, such as Windows Server 2016 and 2019, which are not susceptible to this flaw.

At the time of this writing, we are unaware of any “in-the-wild” exploitation for CVE-2021-31166 but will continue to monitor the threat landscape and provide relevant updates. We urge Windows users to apply the patch immediately wherever possible, giving special attention to externally facing devices that could be compromised from the internet. For those who are unable to apply Microsoft’s update, we are providing a “virtual patch” in the form of a network IPS signature that can be used to detect and prevent exploitation attempts for this vulnerability.

McAfee Network Security Platform (NSP) Protection
Sigset Version: 10.8.21.2
Attack ID: 0x4528f000
Attack Name: HTTP: Microsoft HTTP Protocol Stack Remote Code Execution Vulnerability (CVE-2021-31166)

McAfee Knowledge Base Article KB94510:
https://kc.mcafee.com/corporate/index?page=content&id=KB94510

 

 

The post Major HTTP Vulnerability in Windows Could Lead to Wormable Exploit appeared first on McAfee Blog.

“Fool’s Gold”: Questionable Vaccines, Bogus Results, and Forged Cards

By: Anne An
11 May 2021 at 04:01

Preface

Countries all over the world are racing to achieve so-called herd immunity against COVID-19 by vaccinating their populations. From the initial lockdown to the cancellation of events and the prohibition of business travel, to the reopening of restaurants, and relaxation of COVID restrictions on outdoor gatherings, the vaccine rollout has played a critical role in staving off another wave of infections and restoring some degree of normalcy. However, a new and troubling phenomenon is that consumers are buying COVID-19 vaccines on the black market due to the increased demand around the world. As a result, illegal COVID-19 vaccines and vaccination records are in high demand on darknet marketplaces.

The impact on society is that the proliferation of fraudulent test results and counterfeit COVID-19 vaccine records pose a serious threat to public health and spur the underground economyIndividuals undoubtedly long to return to their pre-pandemic routines and the freedom of travel and behavior denied them over the last year. However, the purchase of false COVID-19 test certifications or vaccination cards to board aircraft, attend an event or enter a country endangers themselves, even if they are asymptomatic. It also threatens the lives of other people in their own communities and around the world. Aside from the collective damage to global health, darknet marketplace transactions encourage the supply of illicit goods and services. The underground economy cycle continues as demand creates inventory, which in turn creates supply. In addition to selling COVID-19 vaccines, vaccination cards, and fake test results, cybercriminals can also benefit by reselling the names, dates of birth, home addresses, contact details, and other personally indefinable information of their customers. 

Racing Toward a Fully Vaccinated Society Along with a Growing Underground Vaccine Market

As we commemorate the one-year anniversary of the COVID-19 pandemic, at least 184 countries and territories worldwide have started their vaccination rollouts.[1] The United States is vaccinating Americans at an unprecedented rate. As of May 2021, more than 105 million Americans had been fully vaccinated. The growing demand has made COVID-19 vaccines the new “liquid gold” in the pandemic era.

However, following vaccination success, COVID-19 related cybercrime has increased. COVID-19 vaccines are currently available on at least a dozen darknet marketplaces. Pfizer-BioNTech COVID-19 vaccines (and we can only speculate as to whether they are genuine or a form of liquid “fool’s gold”) can be purchased for as little as $500 per dose from top-selling vendors. These sellers use various channels, such as Wickr, Telegram, WhatsApp and Gmail, for advertising and communications. Darknet listings associated with alleged Pfizer-BioNTech COVID-19 vaccines are selling for $600 to $2,500. Prospective buyers can receive the product within 2 to 10 days. Some of these supposed COVID-19 vaccines are imported from the United States, while others are packed in the United Kingdom and shipped to every country in the world, according to the underground advertisement.

Figure 1: Dark web marketplace offering COVID-19 vaccines

Figure 2: Dark web marketplace offering COVID-19 vaccines

A vendor sells 10 doses of what they claim to be Moderna COVID-29 vaccines for $2,000. According to the advertisement, the product is available to ship to the United Kingdom and worldwide.

Figure 3: Dark web marketplace offering COVID-19 vaccines

Besides what are claimed to be COVID-19 vaccines, cybercriminals offer antibody home test kits for $152 (again, we do not know whether they are genuine or not). According to the advertisement, there are various shipping options available. It costs $41 for ‘stealth’ shipping to the United States, $10.38 to ship to the United Kingdom, and $20 to mail the vaccines internationally.

Figure 4: Dark web marketplace offering COVID-19 test kits

Proof of Vaccination in the Underground Market

On the darknet marketplaces, the sales of counterfeit COVID-19 test results and vaccination certificates began to outnumber the COVID vaccine offerings in mid-April. This shift is most likely because COVID-19 vaccines are now readily available for those who want them. People can buy and show these certificates without being vaccinated. A growing number of colleges will require students to have received a COVID-19 vaccine before returning to in-person classes by this fall.[2] Soon, COVID-19 vaccination proof is likely to become a requirement of some type of “passport” to board a plane or enter major events and venues.

The growing demand for proof of vaccination is driving an illicit economy for fake vaccination and test certificates. Opportunistic cybercriminals capitalize on public interest in obtaining a COVID-19 immunity passport, particularly for those who oppose COVID-19 vaccines or test positive for COVID-19 but want to return to school or work, resume travel or attend a public event. Counterfeit negative COVID-19 test results and COVID-19 vaccination cards are available for sale at various darknet marketplaces. Fake CDC-issued vaccination cards are available for $50. One vendor offers counterfeit German COVID-19 certificates for $23.35. Vaccination cards with customized information, such as “verified” batch or lot numbers for particular dates and “valid” medical and hospital information, are also available for purchase.

One darknet marketplace vendor offers to sell a digital copy of the COVID-19 vaccination card with detailed printing instructions for $50.

Figure 5: Dark web marketplace offering COVID-19 vaccination cards

One vendor sells CDC vaccination cards for $1,200 and $1,500, as seen in the following screenshot. These cards, according to the advertisement, can be personalized with details such as the prospective buyer’s name and medical information.

Figure 6: Dark web marketplace offering COVID-19 vaccination cards

Other darknet marketplace vendors offer fake CDC-issued COVID-19 vaccination card packages for $1,200 to $2,500. The package contains a PDF file that buyers can type and print, as well as personalized vaccination cards with “real” lot numbers, according to the advertisement. Prospective buyers can pay $1,200 for blank cards or $1,500 for custom-made cards with valid batch numbers, medical and hospital details.

Figure 7: Dark web marketplace offering COVID-19 vaccination cards

One vendor offers counterfeit negative COVID-19 test results and vaccine passports to potential buyers.

Figure 8: Dark web marketplace offering negative COVID-19 test results and vaccination cards

A seller on another dark web market sells five counterfeit German COVID-19 certificates for $23.35. According to the advertisement below, the product is available for shipping to Germany and the rest of the world.

Figure 9: Dark web marketplace offering German COVID-19 vaccination certificates

Conclusion

The proliferation of fraudulent test results and counterfeit COVID-19 vaccine records on darknet marketplaces poses a significant threat to global health while fueling the underground economyWhile an increasing number of countries begin to roll out COVID-19 vaccines and proof of vaccination, questionable COVID vaccines and fake proofs are emerging on the underground market. With the EU and other jurisdictions opening their borders to those who have received vaccinations, individuals will be tempted to obtain false vaccination documents in their drive to a return to pre-pandemic normalcy that includes summer travel and precious time with missed loved ones. Those who buy questionable COVID-19 vaccines or forged vaccination certificaterisk their own lives and the lives of others. Apart from the harm to global health, making payments to darknet marketplaces promotes the growth of illegal products and services. The cycle of the underground economy continues as demand generates inventory, which generates supply. These are the unintended consequences of an effective global COVID vaccine rollout. 

[1] https[:]//www.cnn.com/interactive/2021/health/global-covid-vaccinations/

[2] https[:]//www.npr.org/2021/04/11/984787779/should-colleges-require-covid-19-vaccines-for-fall-more-campuses-are-saying-yes

The post “Fool’s Gold”: Questionable Vaccines, Bogus Results, and Forged Cards appeared first on McAfee Blog.

Roaming Mantis Amplifies Smishing Campaign with OS-Specific Android Malware

5 May 2021 at 18:17
Quel antivirus choisir ?

The Roaming Mantis smishing campaign has been impersonating a logistics company to steal SMS messages and contact lists from Asian Android users since 2018. In the second half of 2020, the campaign improved its effectiveness by adopting dynamic DNS services and spreading messages with phishing URLs that infected victims with the fake Chrome application MoqHao.

Since January 2021, however, the McAfee Mobile Research team has established that Roaming Mantis has been targeting Japanese users with a new malware called SmsSpy. The malicious code infects Android users using one of two variants depending on the version of OS used by the targeted devices. This ability to download malicious payloads based on OS versions enables the attackers to successfully infect a much broader potential landscape of Android devices.

Smishing Technique

The phishing SMS message used is similar to that of recent campaigns, yet the phishing URL contains the term “post” in its composition.

Japanese message: I brought back your luggage because you were absent. please confirm. hxxps://post[.]cioaq[.]com

 

Fig: Smishing message impersonating a notification from a logistics company. (Source: Twitter)

Another smishing message pretends to be a Bitcoin operator and then directs the victim to a phishing site where the user is asked to verify an unauthorized login.

Japanese message: There is a possibility of abnormal login to your [bitFlyer] account. Please verify at the following URL: hxxps://bitfiye[.]com

 

Fig: Smishing message impersonating a notification from a bitcoin operator. (Source: Twitter)

During our investigation, we observed the phishing website hxxps://bitfiye[.]com redirect to hxxps://post.hygvv[.]com. The redirected URL contains the word “post” as well and follows the same format as the first screenshot. In this way, the actors behind the attack attempt to expand the variation of the SMS phishing campaign by redirecting from a domain that resembles a target company and service.

Malware Download

Characteristic of the malware distribution platform, different malware is distributed depending on the Android OS version that accessed the phishing page. On Android OS 10 or later, the fake Google Play app will be downloaded. On Android 9 or earlier devices, the fake Chrome app will be downloaded.

Japanese message in the dialog: “Please update to the latest version of Chrome for better security.”

Fig: Fake Chrome application for download (Android OS 9 or less)

 

Japanese message in the dialog: “[Important] Please update to the latest version of Google Play for better security!”

 

Fig: Fake Google Play app for download (Android OS 10 or above)

Because the malicious program code needs to be changed with each major Android OS upgrade, the malware author appears to cover more devices by distributing malware that detects the OS, rather than attempting to cover a smaller set with just one type of malware

Technical Behaviors

The main purpose of this malware is to steal phone numbers and SMS messages from infected devices. After it runs, the malware pretends to be a Chrome or Google Play app that then requests the default messaging application to read the victim’s contacts and SMS messages. It pretends to be a security service by Google Play on the latest Android device. Additionally, it can also masquerade as a security service on the latest Android devices. Examples of both are seen below.

Japanese message: “At first startup, a dialog requesting permissions is displayed. If you do not accept it, the app may not be able to start, or its functions may be restricted.”

 

Fig: Default messaging app request by fake Chrome app

 

Japanese message: “Secure Internet Security. Your device is protected. Virus and Spyware protection, Anti-phishing protection and Spam mail protection are all checked.”

Fig: Default messaging app request by fake Google Play app

After hiding its icon, the malware establishes a WebSocket connection for communication with the attacker’s command and control (C2) server in the background. The default destination address is embedded in the malware code. It further has link information to update the C2 server location in the event it is needed. Thus, if no default server is detected, or if no response is received from the default server, the C2 server location will be obtained from the update link.

The MoqHao family hides C2 server locations in the user profile page of a blog service, yet some samples of this new family use a Chinese online document service to hide C2 locations. Below is an example of new C2 server locations from an online document:

Fig: C2 server location described in online document

As part of the handshake process, the malware sends the Android OS version, phone number, device model, internet connection type (4G/Wi-Fi), and unique device ID on the infected device to the C2 server.

Then it listens for commands from the C2 server. The sample we analyzed supported the commands below with the intention of stealing phone numbers in Contacts and SMS messages.

Command String Description
通讯录 Send whole contact book to server
收件箱 Send all SMS messages to server
拦截短信&open Start <Delete SMS message>
拦截短信&close Stop <Delete SMS message>
发短信& Command data contains SMS message and destination number, send them via infected device

Table: Remote commands via WebSocket

Conclusion

We believe that the ongoing smishing campaign targeting Asian countries is using different mobile malware such as MoqHao, SpyAgent, and FakeSpy. Based on our research, the new type of malware discovered this time uses a modified infrastructure and payloads. We believe that there could be several groups in the cyber criminals and each group is developing their attack infrastructures and malware separately. Or it could be the work of another group who took advantage of previously successful cyber-attacks.

McAfee Mobile Security detects this threat as Android/SmsSpy and alerts mobile users if it is present and further protects them from any data loss. For more information about McAfee Mobile Security, visit https://www.mcafeemobilesecurity.com.

Appendix – IoC

C2 Servers:

  • 168[.]126[.]149[.]28:7777
  • 165[.]3[.]93[.]6:7777
  • 103[.]85[.]25[.]165:7777

Update Links:

  • r10zhzzfvj[.]feishu.cn/docs/doccnKS75QdvobjDJ3Mh9RlXtMe
  • 0204[.]info
  • 0130one[.]info
  • 210302[.]top
  • 210302bei[.]top

Phishing Domains:

Domain Registration Date
post.jpostp.com 2021-03-15
manag.top 2021-03-11
post.niceng.top 2021-03-08
post.hygvv.com 2021-03-04
post.cepod.xyz 2021-03-04
post.jposc.com 2021-02-08
post.ckerr.site 2021-02-06
post.vioiff.com 2021-02-05
post.cioaq.com 2021-02-04
post.tpliv.com 2021-02-03
posk.vkiiu.com 2021-02-01
sagawae.kijjh.com 2021-02-01
post.viofrr.com 2021-01-31
posk.ficds.com 2021-01-30
sagawae.ceklf.com 2021-01-30
post.giioor.com 2021-01-30
post.rdkke.com 2021-01-29
post.japqn.com 2021-01-29
post.thocv.com 2021-01-28
post.xkdee.com 2021-01-27
post.sagvwa.com 2021-01-25
post.aiuebc.com 2021-01-24
post.postkp.com 2021-01-23
post.solomsn.com 2021-01-22
post.civrr.com 2021-01-21
post.jappnve.com 2021-01-19
sp.vvsscv.com 2021-01-16
ps.vjiir.com 2021-01-15
post.jpaeo.com 2021-01-12
t.aeomt.com 2021-01-2

 

Sample Hash information:

Hash Package name Fake Application
EA30098FF2DD1D097093CE705D1E4324C8DF385E7B227C1A771882CABEE18362 com.gmr.keep Chrome
29FCD54D592A67621C558A115705AD81DAFBD7B022631F25C3BAAE954DB4464B com.gmr.keep Google Play
9BEAD1455BFA9AC0E2F9ECD7EDEBFDC82A4004FCED0D338E38F094C3CE39BCBA com.mr.keep Google Play
D33AB5EC095ED76EE984D065977893FDBCC12E9D9262FA0E5BC868BAD73ED060 com.mrc.keep Chrome
8F8C29CC4AED04CA6AB21C3C44CCA190A6023CE3273EDB566E915FE703F9E18E com.hhz.keeping Chrome
21B958E800DB511D2A0997C4C94E6F0113FC4A8C383C73617ABCF1F76B81E2FD com.hhz.keeping Google Play
7728EF0D45A337427578AAB4C205386CE8EE5A604141669652169BA2FBA23B30 com.hz.keep3 Chrome
056A2341C0051ACBF4315EC5A6EEDD1E4EAB90039A6C336CC7E8646C9873B91A com.hz.keep3 Google Play
054FA5F5AD43B6D6966CDBF4F2547EDC364DDD3D062CD029242554240A139FDB com.hz.keep2 Google Play
DD40BC920484A9AD1EEBE52FB7CD09148AA6C1E7DBC3EB55F278763BAF308B5C com.hz.keep2 Chrome
FC0AAE153726B7E0A401BD07C91B949E8480BAA0E0CD607439ED01ABA1F4EC1A com.hz.keep1 Google Play
711D7FA96DFFBAEECEF12E75CE671C86103B536004997572ECC71C1AEB73DEF6 com.hz.keep1 Chrome
FE916D1B94F89EC308A2D58B50C304F7E242D3A3BCD2D7CCC704F300F218295F com.hz.keep1 Google Play
3AA764651236DFBBADB28516E1DCB5011B1D51992CB248A9BF9487B72B920D4C com.hz.keep1 Chrome
F1456B50A236E8E42CA99A41C1C87C8ED4CC27EB79374FF530BAE91565970995 com.hz.keep Google Play
77390D07D16E6C9D179C806C83D2C196A992A9A619A773C4D49E1F1557824E00 com.hz.keep Chrome
49634208F5FB8BCFC541DA923EBC73D7670C74C525A93B147E28D535F4A07BF8 com.hz.keep Chrome
B5C45054109152F9FE76BEE6CBBF4D8931AE79079E7246AA2141F37A6A81CBA3 com.hz.keep Google Play
85E5DBEA695A28C3BA99DA628116157D53564EF9CE14F57477B5E3095EED5726 com.hz.keep Chrome
53A5DD64A639BF42E174E348FEA4517282C384DD6F840EE7DC8F655B4601D245 com.hz.keep Google Play
80B44D23B70BA3D0333E904B7DDDF7E19007EFEB98E3B158BBC33CDA6E55B7CB com.hz.keep Chrome
797CEDF6E0C5BC1C02B4F03E109449B320830F5ECE0AA6D194AD69E0FE6F3E96 com.hz.keep Chrome
691687CB16A64760227DCF6AECFE0477D5D983B638AFF2718F7E3A927EE2A82C com.hz.keep Google Play
C88C3682337F7380F59DBEE5A0ED3FA7D5779DFEA04903AAB835C959DA3DCD47 com.hz.keep Google Play

 

The post Roaming Mantis Amplifies Smishing Campaign with OS-Specific Android Malware appeared first on McAfee Blog.

How to Stop the Popups

5 May 2021 at 18:06

McAfee is tracking an increase in the use of deceptive popups that mislead some users into taking action, while annoying many others.  A significant portion is attributed to browser-based push notifications, and while there are a couple of simple steps users can take to prevent and remediate the situation, there is also some confusion about how these should be handled.

How does this happen?

In many cases scammers use deception to trick users into Allowing push notifications to be delivered to their system.

In other cases, there is no deception involved.  Users willingly opt-in uncoerced.

What happens next?

After Allowing notifications, messages quickly start being received.  Some sites send notifications as often as every minute.

Many messages are deceptive in nature.  Consider this fake alert example.  Clicking the message leads to an imposter Windows Defender alert website, complete with MP3 audio and a phone number to call.

In several other examples, social engineering is crafted around the McAfee name and logo.  Clicking on the messages lead to various websites informing the user their subscription has expired, that McAfee has detected threats on their system, or providing direct links to purchase a McAfee subscription.  Note that “Remove Ads” and similar notification buttons typically lead to the publishers chosen destination rather than anything that would help the user in disabling the popups.  Also note that many of the destination sites themselves prompt the user to Allow more notifications.  This can have a cascading effect where the user is soon flooded with many messages on a regular basis.

 

How can this be remediated?

First, it’s important to understand that the representative images provided here are not indications of a virus infection.  It is not necessary to update or purchase software to resolve the matter.  There is a simple fix:

1. Note the name of the site sending the notification in the popup itself. It’s located next to the browser name, for example:

Example popup with a link to a Popup remover

2. Go to your browser settings’ notification section

3. Search for the site name and click the 3 dotes next to the entry.

Chrome’s notification settings

4. Select Block

Great, but how can this be prevented in the future?

The simplest way is to carefully read such authorization prompts and only click Allow on sites that you trust.  Alternatively, you can disable notification prompts altogether.

As the saying goes, an ounce of prevention is worth a pound of cure.

What other messages should I be on the lookout for?

While there are thousands of various messages and sites sending them, and messages evolve over time, these are the most common seen in April 2021:

  • Activate Protection Now?|Update Available: Antivirus
  • Activate your free security today – Download now|Turn On Windows Protection ✅
  • Activate your McAfee, now! ✅|Click here to review your PC protection
  • Activate your Mcafee, now! ✅|Reminder From McAfee
  • Activate your Norton, now! ✅|Click here to review your PC protection
  • Activate Your PC Security ✅|Download your free Windows protection now.
  • Antivirus Gratis Installieren✅|Bestes Antivirus–Kostenlos herunterladen
  • Antivirus Protection|Download Now To Protect Your Computer From Viruses &amp; Malware Attacks
  • Best Antivirus 2020 – Download Free Now|Install Your Free Antivirus ✅
  • Check here with a Free Virus Scan|Is Windows slow due to virus?
  • Click here to activate McAfee protection|McAfee Safety Alert
  • Click here to activate McAfee protection|Turn on your antivirus
  • Click Here To Activate McAfee Protection|Upgrade Your Antivirus
  • Click here to activate Norton protection|Turn on your antivirus ✅
  • Click here to clean.|System is infected!
  • Click here to fix the error|Protect your PC now !
  • Click here to fix the error|System alert!
  • Click here to protect your data.|Remove useless files advised
  • Click Here To Renew Subscription|Viruses Found (3)
  • Click here to review your PC protection|⚠ Your Mcafee has Expired
  • Click here to Scan and Remove Virus|Potential Virus?
  • Click To Renew Your Subscription|Viruses Found (3)
  • Click to turn on your Norton protection|New (1) Security Notification
  • Critical Virus Alert|Turn on virus protection
  • Free Antivirus Update is|available.Download and protect system?
  • Install Antivirus Now!|Norton – Protect Your PC!
  • Install FREE Antivirus now|Is the system under threat?
  • Install free antivirus|Protect your Windows PC!
  • Jetzt KOSTENLOSES Antivirus installieren|Wird das System bedroht?
  • McAfee Safety Alert|Turn on your antivirus now [Activate]
  • McAfee Total Protection|Trusted Antivirus and Privacy Protection
  • Norton Antivirus|Stay Protected. Activate Now!
  • Norton Expired 3 Days Ago!⚠ |Renew now to stay protected for your PC!
  • PC is under virus threat! |Renew Norton now to say protected ⚠
  • Protect Your Computer From Viruses|⚠ Activate McAfee Antivirus
  • Renew McAfee License Now!|Stay Protected. Renew Now!
  • Renew McAfee License Now!|Your McAfee Has Expired Today
  • Renew Norton License Now!|Your Norton Has Expired Today
  • Renew Now For 2021|Your Norton has Expired Today?
  • Renew now to stay protected!|⚠ Your Mcafee has Expired
  • Scan Report Ready|Tap to reveal
  • Turn on virus protection|Viruses found (3)
  • Your Computer Might be At Risk ☠ |❌ Renew Norton Antivirus!

General safety tips

  • Scams can be quite convincing. It’s better to be quick to block something and slow to allow than the opposite.
  • When in doubt, initiate the communication yourself.
    • Manually enter in a web address rather than clicking a link sent to you.
    • Confirm numbers and addresses before reaching out, such as phone and email.
  • McAfee customers utilizing web protection (including McAfee Web Advisor and McAfee Web Control) are protected from known malicious sites.

The post How to Stop the Popups appeared first on McAfee Blog.

Access Token Theft and Manipulation Attacks – A Door to Local Privilege Escalation

20 April 2021 at 15:27
how to run a virus scan

Executive Summary

Many malware attacks designed to inflict damage on a network are armed with lateral movement capabilities. Post initial infection, such malware would usually need to perform a higher privileged task or execute a privileged command on the compromised system to be able to further enumerate the infection targets and compromise more systems on the network. Consequently, at some point during its lateral movement activities, it would need to escalate its privileges using one or the other privilege escalation techniques. Once malware or an attacker successfully escalates its privileges on the compromised system, it will acquire the ability to perform stealthier lateral movement, usually executing its tasks under the context of a privileged user, as well as bypassing mitigations like User Account Control.

Process access token manipulation is one such privilege escalation technique which is widely adopted by malware authors. These set of techniques include process access token theft and impersonation, which eventually allows malware to advance its lateral movement activities across the network in the context of another logged in user or higher privileged user.

When a user authenticates to Windows via console (interactive logon), a logon session is created, and an access token is granted to the user. Windows manages the identity, security, or access rights of the user on the system with this access token, essentially determining what system resources they can access and what tasks can be performed. An access token for a user is primarily a kernel object and an identification of that user in the system, which also contains many other details like groups, access rights, integrity level of the process, privileges, etc. Fundamentally, a user’s logon session has an access token which also references their credentials to be used for Windows single sign on (SSO) authentication to access the local or remote network resources.

Once the attacker gains an initial foothold on the target by compromising the initial system, they would want to move around the network laterally to access more resource or critical assets. One of the ways for an attacker to achieve this is to use the identity or credentials of already logged-on users on the compromised machine to pivot to other systems or escalate their privileges and perform the lateral movement in the context of another logged on higher privileged user. Process access token manipulation helps the attackers to precisely accomplish this goal.

For our YARA rule, MITRE ATT&CK techniques and to learn more about the technical details of token manipulation attacks and how malware executes these attacks successfully at the code level, read our complete technical analysis here.

Coverage

McAfee On-Access-Scan has a generic detection for this nature of malware  as shown in the below screenshot:

Additionally, the YARA rule mentioned at the end of the technical analysis document can also be used to detect the token manipulation attacks by importing the rule in the Threat detection solutions like McAfee Advance Threat Defence, this behaviour can be detected.

Summary of the Threat

Several types of malware and advanced persistent threats abuse process tokens to gain elevated privileges on the system. Malware can take multiple routes to achieve this goal. However, in all these routes, it would abuse the Windows APIs to execute the token stealing or token impersonation to gain elevated privileges and advance its lateral movement activities.

  • If the current logged on user on the compromised or infected machine is a part of the administrator group of users OR running a process with higher privileges (e.g., by using “runas” command), malware can abuse the privileges of the process’s access token to elevate its privileges on the system, thereby enabling itself to perform privileged tasks.
  • Malware can use multiple Windows APIs to enumerate the Windows processes running with higher privileges (usually SYSTEM level privileges), acquire the access tokens of those processes and start new processes with the acquired token. This results in the new process being started in the context of the user represented by the token, which is SYSTEM.
  • Malware can also execute a token impersonation attack where it can duplicate the access tokens of the higher privileged SYSTEM level process, convert it into the impersonation token by using appropriate Windows functionality and then impersonate the SYSTEM user on the infected machine, thereby elevating its privileges.
  • These token manipulation attacks will allow malware to use the credentials of the current logged on user or the credentials of another privileged user to authenticate to the remote network resource, leading to advancement of its lateral movement activities.
  • These attack techniques allows malware to bypass multiple mitigations like UAC, access control lists, heuristics detection techniques and allowing malware to remain stealthier while moving laterally inside the network.

 

Access Token Theft and Manipulation Attacks – Technical Analysis

Access Token Theft and Manipulation Attacks – A Door to Local Privilege Escalation.

Read Now

 

The post Access Token Theft and Manipulation Attacks – A Door to Local Privilege Escalation appeared first on McAfee Blog.

Clever Billing Fraud Applications on Google Play: Etinu

19 April 2021 at 21:42
Saibāsekyuriti

Authored by: Sang Ryol Ryu and Chanung Pak

A new wave of fraudulent apps has made its way to the Google Play store, targeting Android users in Southwest Asia and the Arabian Peninsula as well—to the tune of more than 700,000 downloads before detection by McAfee Mobile Research and co-operation with Google to remove the apps.

Figure 1. Infected Apps on Google Play

Posing as photo editors, wallpapers, puzzles, keyboard skins, and other camera-related apps, the malware embedded in these fraudulent apps hijack SMS message notifications and then make unauthorized purchases. While apps go through a review process to ensure that they are legitimate, these fraudulent apps made their way into the store by submitting a clean version of the app for review and then introducing the malicious code via updates to the app later.

Figure 2. Negative reviews on Google Play

McAfee Mobile Security detects this threat as Android/Etinu and alerts mobile users if they are present. The McAfee Mobile Research team continues to monitor this threat and is likewise continuing its co-operation with Google to remove these and other malicious applications on Google Play.

Technical analysis

In terms of details, the malware embedded in these apps takes advantage of dynamic code loading. Encrypted payloads of malware appear in the assets folder associated with the app, using names such as “cache.bin,” “settings.bin,” “data.droid,” or seemingly innocuous “.png” files, as illustrated below.

Figure 3. Encrypted resource sneaked into the assets folder

Figure 4. Decryption flow

The figure above shows the decryption flow. Firstly, the hidden malicious code in the main .apk opens “1.png” file in the assets folder, decrypts it to “loader.dex,” and then loads the dropped .dex. The “1.png” is encrypted using RC4 with the package name as the key. The first payload creates HTTP POST request to the C2 server.

Interestingly, this malware uses key management servers. It requests keys from the servers for the AES encrypted second payload, “2.png”. And the server returns the key as the “s” value of JSON. Also, this malware has self-update function. When the server responds “URL” value, the content in the URL is used instead of “2.png”. However, servers do not always respond to the request or return the secret key.

Figure 5. Updated payload response

As always, the most malicious functions reveal themselves in the final stage. The malware hijacks the Notification Listener to steal incoming SMS messages like Android Joker malware does, without the SMS read permission. Like a chain system, the malware then passes the notification object to the final stage. When the notification has arisen from the default SMS package, the message is finally sent out using WebView JavaScript Interface.

Figure 6. Notification delivery flow

As a result of our additional investigation on C2 servers, following information was found, including carrier, phone number, SMS message, IP address, country, network status, and so forth—along with auto-renewing subscriptions:

Figure 7. Leaked data

Further threats like these to come?

We expect that threats which take advantage of Notification Listener will continue to flourish. The McAfee Mobile Research team continues to monitor these threats and protect customers by analyzing potential malware and working with app stores to remove it. Further, using McAfee Mobile Security can detect such threats and protect you from them via its regular updates. However, it’s important to pay attention to apps that request SMS-related permissions and Notification Listener permissions. Simply put, legitimate photo and wallpaper apps simply won’t ask for those because they’re not necessary for such apps to run. If a request seems suspicious, don’t allow it.

Technical Data and IOCs

MITRE ATT&CK Matrix

IoCs

08C4F705D5A7C9DC7C05EDEE3FCAD12F345A6EE6832D54B758E57394292BA651 com.studio.keypaper2021
CC2DEFEF5A14F9B4B9F27CC9F5BBB0D2FC8A729A2F4EBA20010E81A362D5560C com.pip.editor.camera
007587C4A84D18592BF4EF7AD828D5AAA7D50CADBBF8B0892590DB48CCA7487E org.my.favorites.up.keypaper
08FA33BC138FE4835C15E45D1C1D5A81094E156EEF28D02EA8910D5F8E44D4B8 com.super.color.hairdryer
9E688A36F02DD1B1A9AE4A5C94C1335B14D1B0B1C8901EC8C986B4390E95E760 com.ce1ab3.app.photo.editor
018B705E8577F065AC6F0EDE5A8A1622820B6AEAC77D0284852CEAECF8D8460C com.hit.camera.pip
0E2ACCFA47B782B062CC324704C1F999796F5045D9753423CF7238FE4CABBFA8 com.daynight.keyboard.wallpaper
50D498755486D3739BE5D2292A51C7C3D0ADA6D1A37C89B669A601A324794B06 com.super.star.ringtones

URLs

d37i64jgpubcy4.cloudfront.net

d1ag96m0hzoks5.cloudfront.net

dospxvsfnk8s8.cloudfront.net

d45wejayb5ly8.cloudfront.net

d3u41fvcv6mjph.cloudfront.net

d3puvb2n8wcn2r.cloudfront.net

d8fkjd2z9mouq.cloudfront.net

d22g8hm4svq46j.cloudfront.net

d3i3wvt6f8lwyr.cloudfront.net

d1w5drh895wnkz.cloudfront.net

The post Clever Billing Fraud Applications on Google Play: Etinu appeared first on McAfee Blog.

McAfee Labs Report Reveals Latest COVID-19 Threats and Malware Surges

13 April 2021 at 04:01

The McAfee Advanced Threat Research team today published the McAfee Labs Threats Report: April 2021.

In this edition, we present new findings in our traditional threat statistical categories – as well as our usual malware, sectors, and vectors – imparted in a new, enhanced digital presentation that’s more easily consumed and interpreted.

Historically, our reports detailed the volume of key threats, such as “what is in the malware zoo.” The introduction of MVISION Insights in 2020 has since made it possible to track the prevalence of campaigns, as well as, their associated IoCs, and determine the in-field detections. This latest report incorporates not only the malware zoo but new analysis for what is being detected in the wild.

The Q3 and Q4 2020 findings include:

  • COVID-19-themed cyber-attack detections increased 114%
  • New malware samples averaging 648 new threats per minute
  • 1 million external attacks observed against MVISION Cloud user accounts
  • Powershell threats spiked 208%
  • Mobile malware surged 118%

Additional Q3 and Q4 2020 content includes:

  • Leading MITRE ATT&CK techniques
  • Prominent exploit vulnerabilities
  • McAfee research of the prolific SUNBURST/SolarWinds campaign

These new, insightful additions really make for a bumper report! We hope you find this new McAfee Labs threat report presentation and data valuable.

Don’t forget keep track of the latest campaigns and continuing threat coverage by visiting our McAfee COVID-19 Threats Dashboard and the MVISION Insights preview dashboard.

The post McAfee Labs Report Reveals Latest COVID-19 Threats and Malware Surges appeared first on McAfee Blog.

BRATA Keeps Sneaking into Google Play, Now Targeting USA and Spain

12 April 2021 at 16:13
How to check for viruses

Recently, the McAfee Mobile Research Team uncovered several new variants of the Android malware family BRATA being distributed in Google Play, ironically posing as app security scanners.

These malicious apps urge users to update Chrome, WhatsApp, or a PDF reader, yet instead of updating the app in question, they take full control of the device by abusing accessibility services. Recent versions of BRATA were also seen serving phishing webpages targeting users of financial entities, not only in Brazil but also in Spain and the USA.

In this blog post we will provide an overview of this threat, how does this malware operates and its main upgrades compared with earlier versions. If you want to learn more about the technical details of this threat and the differences between all variants you can check the BRATA whitepaper here.

The origins of BRATA

First seen in the wild at the end of 2018 and named “Brazilian Remote Access Tool Android ” (BRATA) by Kaspersky, this “RAT” initially targeted users in Brazil and then rapidly evolved into a banking trojan. It combines full device control capabilities with the ability to display phishing webpages that steal banking credentials in addition to abilities that allow it capture screen lock credentials (PIN, Password or Pattern), capture keystrokes (keylogger functionality), and record the screen of the infected device to monitor a user’s actions without their consent.

Because BRATA is distributed mainly on Google Play, it allows bad actors to lure victims into installing these malicious apps pretending that there is a security issue on the victim’s device and asking to install a malicious app to fix the problem. Given this common ruse, it is recommended to avoid clicking on links from untrusted sources that pretend to be a security software which scans and updates your system—e even if that link leads to an app in Google Play. McAfee offers protection against this threat via McAfee Mobile Security, which detects this malware as Android/Brata.

How BRATA Android malware has evolved and targets new victims

The main upgrades and changes that we have identified in the latest versions of BRATA recently found in Google Play include:

  • Geographical expansion: Initially targeting Brazil, we found that recent variants started to also target users in Spain and the USA.
  • Banking trojan functionality: In addition to being able to have full control of the infected device by abusing accessibility services, BRATA is now serving phishing URLs based on the presence of certain financial and banking apps defined by the remote command and control server.
  • Self-defense techniques: New BRATA variants added new protection layers like string obfuscation, encryption of configuration files, use of commercial packers, and the move of its core functionality to a remote server so it can be easily updated without changing the main application. Some BRATA variants also check first if the device is worth being attacked before downloading and executing their main payload, making it more evasive to automated analysis systems.

BRATA in Google Play

During 2020, the threat actors behind BRATA have managed to publish several apps in Google Play, most of them reaching between one thousand to five thousand installs. However, also a few variants have reached 10,000 installs including the latest one, DefenseScreen, reported to Google by McAfee in October and later removed from Google Play.

Figure 1. DefenseScreen app in Google Play.

From all BRATA apps that were in Google Play in 2020, five of them caught our attention as they have notable improvements compared with previous ones. We refer to them by the name of the developer accounts:

Figure 2. Timeline of identified apps in Google Play from May to October 2020

Social engineering tricks

BRATA poses as a security app scanner that pretends to scan all the installed apps, while in the background it checks if any of the target apps provided by a remote server are installed in the user’s device. If that is the case, it will urge the user to install a fake update of a specific app selected depending on the device language. In the case of English-language apps, BRATA suggests the update of Chrome while also constantly showing a notification at the top of the screen asking the user to activate accessibility services:

Figure 3. Fake app scanning functionality

Once the user clicks on “UPDATE NOW!”, BRATA proceeds to open the main Accessibility tab in Android settings and asks the user to manually find the malicious service and grant permissions to use accessibility services. When the user attempts to do this dangerous action, Android warns of the potential risks of granting access to accessibility services to a specific app, including that the app can observe your actions, retrieve content from Windows, and perform gestures like tap, swipe, and pinch.

As soon as the user clicks on OK the persistent notification goes away, the main icon of the app is hidden and a full black screen with the word “Updating” appears, which could be used to hide automated actions that now can be performed with the abuse of accessibility services:

Figure 4. BRATA asking access to accessibility services and showing a black screen to potentially hide automated actions

At this point, the app is completely hidden from the user, running in the background in constant communication with a command and control server run by the threat actors. The only user interface that we saw when we analyzed BRATA after the access to accessibility services was granted was the following screen, created by the malware to steal the device PIN and use it to unlock it when the phone is unattended. The screen asks the user to confirm the PIN, validating it with the real one because when an incorrect PIN is entered, an error message is shown and the screen will not disappear until the correct PIN is entered:

Figure 5. BRATA attempting to steal device PIN and confirming if the correct one is provided

BRATA capabilities

Once the malicious app is executed and accessibility permissions have been granted, BRATA can perform almost any action in the compromised device. Here’s the list of commands that we found in all the payloads that we have analyzed so far:

  • Steal lock screen (PIN/Password/Pattern)
  • Screen Capture: Records the device’s screen and sends screenshots to the remote server
  • Execute Action: Interact with user’s interface by abusing accessibility services
  • Unlock Device: Use stolen PIN/Password/Pattern to unlock the device
  • Start/Schedule activity lunch: Opens a specific activity provided by the remote server
  • Start/Stop Keylogger: Captures user’s input on editable fields and leaks that to a remote server
  • UI text injection: Injects a string provided by the remote server in an editable field
  • Hide/Unhide Incoming Calls: Sets the ring volume to 0 and creates a full black screen to hide an incoming call
  • Clipboard manipulation: Injects a string provided by the remote server in the clipboard

In addition to the commands above, BRATA also performs automated actions by abusing accessibility services to hide itself from the user or automatically grant privileges to itself:

  • Hides the media projection warning message that explicitly warns the user that the app will start capturing everything displayed on the screen.
  • Grants itself any permissions by clicking on the “Allow” button when the permission dialog appears in the screen.
  • Disables Google Play Store and therefore Google Play Protect.
  • Uninstalls itself in case that the Settings interface of itself with the buttons “Uninstall” and “Force Stop” appears in the screen.

Geographical expansion and Banking Trojan Functionality

Earlier BRATA versions like OutProtect and PrivacyTitan were designed to target Brazilian users only by limiting its execution to devices set to the Portuguese language in Brazil. However, in June we noticed that threat actors behind BRATA started to add support to other languages like Spanish and English. Depending on the language configured in the device, the malware suggested that one of the following three apps needed an urgent update: WhatsApp (Spanish), a non-existent PDF Reader (Portuguese) and Chrome (English):

Figure 6. Apps falsely asked to be updated depending on the device language

In addition to the localization of the user-interface strings, we also noticed that threat actors have updated the list of targeted financial apps to add some from Spain and USA. In September, the target list had around 52 apps but only 32 had phishing URLs. Also, from the 20 US banking apps present in the last target list only 5 had phishing URLs. Here’s an example of phishing websites that will be displayed to the user if specific US banking apps are present in the compromised device:

Figure 7. Examples of phishing websites pretending to be from US banks

Multiple Obfuscation Layers and Stages

Throughout 2020, BRATA constantly evolved, adding different obfuscation layers to impede its analysis and detection. One of the first major changes was moving its core functionality to a remote server so it can be easily updated without changing the original malicious application. The same server is used as a first point of contact to register the infected device, provide an updated list of targeted financial apps, and then deliver the IP address and port of the server that will be used by the attackers to execute commands remotely on the compromised device:

 

Figure 8. BRATA high level network communication

Additional protection layers include string obfuscation, country and language check, encryption of certain key strings in assets folder, and, in latest variants, the use of a commercial packer that further prevents the static and dynamic analysis of the malicious apps. The illustration below provides a summary of the different protection layers and execution stages present in the latest BRATA variants:

Figure 9. BRATA protection layers and execution stages

Prevention and defense

In order get infected with BRATA ,users must install the malicious application from Google Play so below are some recommendations to avoid being tricked by this or any other Android threats that use social engineering to convince users to install malware that looks legitimate:

  • Don’t trust an Android application just because it’s available in the official store. In this case, victims are mainly lured to install an app that promises a more secure device by offering a fake update. Keep in mind that in Android updates are installed automatically via Google Play so users shouldn’t require the installation of a third-party app to have the device up to date.
  • McAfee Mobile Security will alert users if they are attempting to install or execute a malware even if it’s downloaded from Google Play. We recommend users to have a reliable and updated antivirus installed on their mobile devices to detect this and other malicious applications.
  • Do not click on suspicious links received from text messages or social media, particularly from unknown sources. Always double check by other means if a contact that sends a link without context was really sent by that person, because it could lead to the download of a malicious application.
  • Before installing an app, check the developer information, requested permissions, the number of installations, and the content of the reviews. Sometimes applications could have very good rating but most of the reviews could be fake, such as we uncovered in Android/LeifAccess. Be aware that ranking manipulation happens and that reviews are not always trustworthy.

The activation of accessibility services is very sensitive in Android and key to the successful execution of this banking trojan because, once the access to those services is granted, BRATA can perform all the malicious activities and take control of the device. For this reason, Android users must be very careful when granting this access to any app.

Accessibility services are so powerful that in hands of a malicious app they could be used to fully compromise your device data, your online banking and finances, and your digital life overall.

BRATA Android malware continues to evolve—another good reason for protecting mobile devices

When BRATA was initially discovered in 2019 and named “Brazilian Android RAT” by Kaspersky, it was said that, theoretically, the malware can be used to target other users if the cybercriminals behind this threat wanted to do it. Based on the newest variants found in 2020, the theory has become reality, showing that this threat is currently very active, constantly adding new targets, new languages and new protection layers to make its detection and analysis more difficult.

In terms of functionality, BRATA is just another example of how powerful the (ab)use of accessibility services is and how, with just a little bit of social engineering and persistence, cybercriminals can trick users into granting this access to a malicious app and basically getting total control of the infected device. By stealing the PIN, Password or Pattern, combined with the ability to record the screen, click on any button and intercept anything that is entered in an editable field, malware authors can virtually get any data they want, including banking credentials via phishing web pages or even directly from the apps themselves, while also hiding all these actions from the user.

Judging by our findings, the number of apps found in Google Play in 2020 and the increasing number of targeted financial apps, it looks like BRATA will continue to evolve, adding new functionality, new targets, and new obfuscation techniques to target as many users as possible, while also attempting to reduce the risk of being detected and removed from the Play store.

McAfee Mobile Security detects this threat as Android/Brata. To protect yourselves from this and similar threats, employ security software on your mobile devices and think twice before granting access to accessibility services to suspicious apps, even if they are downloaded from trusted sources like Google Play.

Appendix

Techniques, Tactics and Procedures (TTPS)

Figure 10. MITRE ATT&CK Mobile for BRATA

<h3>Indicators of compromise

Apps:

SHA256 Package Name Installs
4cdbd105ab8117620731630f8f89eb2e6110dbf6341df43712a0ec9837c5a9be com.outprotect.android 1,000+
d9bc87ab45b0c786aa09f964a8101f6df7ea76895e2e8438c13935a356d9116b com.privacytitan.android 1,000+
f9dc40a7dd2a875344721834e7d80bf7dbfa1bf08f29b7209deb0decad77e992 com.greatvault.mobile 10,000+
e00240f62ec68488ef9dfde705258b025c613a41760138b5d9bdb2fb59db4d5e com.pw.secureshield 5,000+
2846c9dda06a052049d89b1586cff21f44d1d28f153a2ff4726051ac27ca3ba7 com.defensescreen.application 10,000+

 

URLs:

  • bialub[.]com
  • brorne[.]com
  • jachof[.]com

 

Technical Analysis of BRATA Apps

This paper will analyze five different “Brazilian Remote Access Tool Android” (BRATA) apps found in Google Play during 2020.

View Now

The post BRATA Keeps Sneaking into Google Play, Now Targeting USA and Spain appeared first on McAfee Blog.

McAfee Defender’s Blog: Cuba Ransomware Campaign

6 April 2021 at 17:00

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.

MITRE Tactic MITRE Techniques CSC Controls McAfee Capability
Initial Access Spear Phishing Attachments (T1566.001) CSC 7 – Email and Web Browser Protection

CSC 8 – Malware Defenses

CSC 17 – User Awareness

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection,

Web Gateway (MWG), Advanced Threat Defense, Web Gateway Cloud Service (WGCS)

Initial Access Spear Phishing Link (T1566.002) CSC 7 – Email and Web Browser Protection

CSC 8 – Malware Defenses

CSC 17 – User Awareness

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection,

Web Gateway (MWG), Advanced Threat Defense, Web Gateway Cloud Service (WGCS)

Initial Access Spear Phishing (T1566.003) Service CSC 7 – Email and Web Browser Protection

CSC 8 – Malware Defenses

CSC 17 – User Awareness

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection,

Web Gateway (MWG), Advanced Threat Defense, Web Gateway Cloud Service (WGCS)

For additional information on how McAfee can protect against suspicious email attachments, review this additional blog post: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/mcafee-protects-against-suspicious-email-attachments/

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.

MITRE Tactic MITRE Techniques CSC Controls McAfee Portfolio Mitigation
Execution User Execution (T1204) CSC 5 Secure Configuration

CSC 8 Malware Defenses

CSC 17 Security Awareness

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control (MAC), Web Gateway and Network Security Platform
Execution Command and Scripting Interpreter (T1059)

 

CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control (MAC), MVISION EDR
Execution Shared Modules (T1129) CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control (MAC)
Persistence Boot or Autologon Execution (T1547) CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7 Threat Prevention, MVISION EDR
Defensive Evasion Template Injection (T1221) CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, MVISION EDR
Defensive Evasion Signed Binary Proxy Execution (T1218) CSC 4 Control Admin Privileges

CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control, MVISION EDR
Defensive Evasion Deobfuscate/Decode Files or Information (T1027)

 

CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, MVISION EDR

For more information on how McAfee Endpoint Security 10.7 can prevent some of the techniques used in the Cuba ransomware exploit stage, review this additional blog post: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/mcafee-amsi-integration-protects-against-malicious-scripts/

Impact Stage Defensive Overview

The impact stage is where the attacker encrypts the target system, data and perhaps moves laterally to other systems on the network. Protection at this stage is heavily dependent on adaptable anti-malware on both end user devices and servers, network controls and security operation’s capability to monitor logs for anomalies in privileged access or network traffic. The following chart summarizes the controls expected to have the most effect against impact stage techniques and the McAfee solutions to implement those controls where applicable:

The public leak site of Cuba ransomware can be found via TOR: http://cuba4mp6ximo2zlo[.]onion/

MITRE Tactic MITRE Techniques CSC Controls McAfee Portfolio Mitigation
Discovery Account Discovery (T1087) CSC 4 Control Use of Admin Privileges

CSC 5 Secure Configuration

CSC 6 Log Analysis

MVISION EDR, MVISION Cloud, Cloud Workload Protection
Discovery System Information Discovery (T1082) CSC 4 Control Use of Admin Privileges

CSC 5 Secure Configuration

CSC 6 Log Analysis

MVISION EDR, MVISION Cloud, Cloud Workload Protection
Discovery System Owner/User Discovery (T1033) CSC 4 Control Use of Admin Privileges

CSC 5 Secure Configuration

CSC 6 Log Analysis

MVISION EDR, MVISION Cloud, Cloud Workload Protection
Command and Control Encrypted Channel (T1573) CSC 8 Malware Defenses

CSC 12 Boundary Defenses

Web Gateway, Network Security Platform

 

Hunting for Cuba Ransomware Indicators

As a threat intel analyst or hunter, you might want to quickly scan your systems for any indicators you received on Cuba ransomware. Of course, you can do that manually by downloading a list of indicators and searching with available tools. However, if you have MVISION EDR and Insights, you can do that right from the console, saving precious time. Hunting the attacker can be a game of inches so every second counts. Of course, if you found infected systems or systems with indicators, you can take action to contain and start an investigation for incident response immediately from the MVISION EDR console.

In addition to these IOCs, YARA rules are available in our technical analysis of Cuba ransomware.

IOCs:

Files:

151.bat

151.ps1

Kurva.ps1

 

Email addresses:

under_amur@protonmail[.]ch

helpadmin2@cock[.]li

helpadmin2@protonmail[.]com

iracomp2@protonmail[.]ch

[email protected]

[email protected]

[email protected]

 

Domain:

kurvalarva[.]com

 

Script for lateral movement and deployment:

54627975c0befee0075d6da1a53af9403f047d9e367389e48ae0d25c2a7154bc

c385ef710cbdd8ba7759e084051f5742b6fa8a6b65340a9795f48d0a425fec61

40101fb3629cdb7d53c3af19dea2b6245a8d8aa9f28febd052bb9d792cfbefa6

 

Cuba Ransomware:

c4b1f4e1ac9a28cc9e50195b29dde8bd54527abc7f4d16899f9f8315c852afd4

944ee8789cc929d2efda5790669e5266fe80910cabf1050cbb3e57dc62de2040
78ce13d09d828fc8b06cf55f8247bac07379d0c8b8c8b1a6996c29163fa4b659
33352a38454cfc247bc7465bf177f5f97d7fd0bd220103d4422c8ec45b4d3d0e

672fb249e520f4496e72021f887f8bb86fec5604317d8af3f0800d49aa157be1
e942a8bcb3d4a6f6df6a6522e4d5c58d25cdbe369ecda1356a66dacbd3945d30

907f42a79192a016154f11927fbb1e6f661f679d68947bddc714f5acc4aa66eb
28140885cf794ffef27f5673ca64bd680fc0b8a469453d0310aea439f7e04e64
271ef3c1d022829f0b15f2471d05a28d4786abafd0a9e1e742bde3f6b36872ad
6396ea2ef48aa3d3a61fb2e1ca50ac3711c376ec2b67dbaf64eeba49f5dfa9df

bda4bddcbd140e4012bab453e28a4fba86f16ac8983d7db391043eab627e9fa1

7a17f344d916f7f0272b9480336fb05d33147b8be2e71c3261ea30a32d73fecb

c206593d626e1f8b9c5d15b9b5ec16a298890e8bae61a232c2104cbac8d51bdd

9882c2f5a95d7680626470f6c0d3609c7590eb552065f81ab41ffe074ea74e82

c385ef710cbdd8ba7759e084051f5742b6fa8a6b65340a9795f48d0a425fec61
54627975c0befee0075d6da1a53af9403f047d9e367389e48ae0d25c2a7154bc
1f825ef9ff3e0bb80b7076ef19b837e927efea9db123d3b2b8ec15c8510da647
40101fb3629cdb7d53c3af19dea2b6245a8d8aa9f28febd052bb9d792cfbefa6

00ddbe28a31cc91bd7b1989a9bebd43c4b5565aa0a9ed4e0ca2a5cfb290475ed

729950ce621a4bc6579957eabb3d1668498c805738ee5e83b74d5edaf2f4cb9e

 

MITRE ATT&CK Techniques:

Tactic Technique Observable IOCs
Execution Command and Scripting Interpreter: PowerShell (T1059.001) Cuba team is using PowerShell payload to drop Cuba ransomware f739977004981fbe4a54bc68be18ea79

68a99624f98b8cd956108fedcc44e07c

bdeb5acc7b569c783f81499f400b2745

 

Execution System Services: Service Execution (T1569.002)  

 

Execution Shared Modules (T1129) Cuba ransomware links function at runtime Functions:

“GetModuleHandle”

“GetProcAddress”

“GetModuleHandleEx”

Execution Command and Scripting Interpreter (T1059) Cuba ransomware accepts command line arguments Functions:

“GetCommandLine”

Persistence Create or Modify System Process: Windows Service (T1543.003) Cuba ransomware can modify services Functions:

“OpenService”

“ChangeServiceConfig”

Privilege Escalation Access Token Manipulation (T1134) Cuba ransomware can adjust access privileges Functions:

“SeDebugPrivilege”

“AdjustTokenPrivileges”

“LookupPrivilegeValue”

Defense Evasion File and Directory Permissions Modification (T1222) Cuba ransomware will set file attributes Functions:

“SetFileAttributes”

Defense Evasion Obfuscated files or Information (T1027) Cuba ransomware is using xor algorithm to encode data
Defense Evasion Virtualization/Sandbox Evasion: System Checks Cuba ransomware executes anti-vm instructions
Discovery File and Directory Discovery (T1083) Cuba ransomware enumerates files Functions:

“FindFirstFile”

“FindNextFile”

“FindClose”

“FindFirstFileEx”

“FindNextFileEx”

“GetFileSizeEx”

Discovery Process Discovery (T1057) Cuba ransomware enumerates process modules Functions:

“K32EnumProcesses”

Discovery System Information Discovery (T1082) Cuba ransomware can get keyboard layout, enumerates disks, etc Functions:

“GetKeyboardLayoutList”

“FindFirstVolume”

“FindNextVolume”

“GetVolumePathNamesForVolumeName”

“GetDriveType”

“GetLogicalDriveStrings”

“GetDiskFreeSpaceEx”

Discovery System Service Discovery (T1007) Cuba ransomware can query service status Functions:

“QueryServiceStatusEx”

Collection Input Capture: Keylogging (T1056.001) Cuba ransomware logs keystrokes via polling Functions:

“GetKeyState”

“VkKeyScan”

Impact Service Stop (T1489) Cuba ransomware can stop services
Impact Data encrypted for Impact (T1486) Cuba ransomware encrypts data

 

Proactively Detecting Cuba Ransomware Techniques

Many of the exploit stage techniques in this attack could use legitimate Windows processes and applications to either exploit or avoid detection. We discussed, above, how the Endpoint Protection Platform can disrupt weaponized documents but, by using MVISION EDR, you can get more visibility. As security analysts, we want to focus on suspicious techniques used by Initial Access, as this attack’s Initial Access is unknown.

Monitoring or Reporting on Cuba Ransomware Events

Events from McAfee Endpoint Protection and McAfee MVISION EDR play a key role in Cuba ransomware incident and threat response. McAfee ePO centralizes event collection from all managed endpoint systems. As a threat responder, you may want to create a dashboard for Cuba ransomware-related threat events to understand your current exposure.

Summary

To defeat targeted threat campaigns, defenders must collaborate internally and externally to build an adaptive security architecture which will make it harder for threat actors to succeed and build resilience in the business. This blog highlights how to use McAfee’s security solutions to prevent, detect and respond to Cuba ransomware and attackers using similar techniques.

McAfee ATR is actively monitoring this campaign and will continue to update McAfee Insights and its social networking channels with new and current information. Want to stay ahead of the adversaries? Check out McAfee Insights for more information.

The post McAfee Defender’s Blog: Cuba Ransomware Campaign appeared first on McAfee Blog.

McAfee ATR Threat Report: A Quick Primer on Cuba Ransomware

6 April 2021 at 17:00

Executive Summary 

Cuba ransomware is an older ransomware, that has recently undergone some development. The actors have incorporated the leaking of victim data to increase its impact and revenue, much like we have seen recently with other major ransomware campaigns. 

In our analysis, we observed that the attackers had access to the network before the infection and were able to collect specific information in order to orchestrate the attack and have the greatest impact. The attackers operate using a set of PowerShell scripts that enables them to move laterally. The ransom note mentions that the data was exfiltrated before it was encrypted. In similar attacks we have observed the use of Cobalt Strike payload, although we have not found clear evidence of a relationship with Cuba ransomware. 

We observed Cuba ransomware targeting financial institutions, industry, technology and logistics organizations.  

The following picture shows an overview of the countries that have been impacted according to our telemetry.  

Coverage and Protection Advice 

Defenders should be on the lookout for traces and behaviours that correlate to open source pen test tools such as winPEASLazagne, Bloodhound and Sharp Hound, or hacking frameworks like Cobalt Strike, Metasploit, Empire or Covenant, as well as abnormal behavior of non-malicious tools that have a dual use. These seemingly legitimate tools (e.g., ADfindPSExec, PowerShell, etc.) can be used for things like enumeration and execution. Subsequently, be on the lookout for abnormal usage of Windows Management Instrumentation WMIC (T1047). We advise everyone to check out the following blogs on evidence indicators for a targeted ransomware attack (Part1Part2).  

Looking at other similar Ransomware-as-a-Service families we have seen that certain entry vectors are quite common among ransomware criminals: 

  • E-mail Spear phishing (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 attackers to continue completely compromising a victim’s network. We have observed this in the past with the likes of Trickbot & Ryuk or Qakbot & Prolock, etc.  
  • Exploit Public-Facing Application (T1190) is another common entry vector, given cyber criminals are often 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 down if you already have the keys? Weakly protected RDP access is a prime example of this entry method. For the best tips on RDP security, please see 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 can be purchased by ransomware criminals to search for VPN and corporate logins. For organizations, having a robust credential management and MFA on user accounts is an absolute must have.  

When it comes to the actual ransomware binary, we strongly advise updating and upgrading endpoint protection, as well as enabling options like tamper protection and Rollback. Please read our blog on how to best configure ENS 10.7 to protect against ransomware for more details. 

For active protection, more details can be found on our website –  https://www.mcafee.com/enterprise/en-us/threat-center/threat-landscape-dashboard/ransomware-details.cuba-ransomware.html – and in our detailed Defender blog. 

Summary of the Threat 

  • Cuba ransomware is currently hitting several companies in north and south America, as well as in Europe.  
  • The attackers use a set of obfuscated PowerShell scripts to move laterally and deploy their attack.  
  • The website to leak the stolen data has been put online recently.  
  • The malware is obfuscated and comes with several evasion techniques.  
  • The actors have sold some of the stolen data 
  • The ransomware uses multiple argument options and has the possibility to discover shared resources using the NetShareEnum API. 

Learn more about Cuba ransomware, Yara Rules, Indicators of Compromise & Mitre ATT&CK techniques used by reading our detailed technical analysis.

The post McAfee ATR Threat Report: A Quick Primer on Cuba Ransomware appeared first on McAfee Blog.

McAfee Defenders Blog: Reality Check for your Defenses

31 March 2021 at 16:22
How to check for viruses

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:

MITRE Tactic Security Capability Example McAfee solution features
Execution Attack surface reduction ENS Access Protection and Exploit Prevention, MVISION Insights recommendations
Multi-layered detection ENS Exploit Prevention, MVISION Insights telemetry, MVISION EDR Tracing, ATD file analysis
Multi-layered protection ENS On-Access-Scanning using Signatures, GTI, Machine-Learning and more
Rule & Risk-based analytics MVISION EDR tracing
Containment ENS Dynamic Application Containment
Persistence Attack surface reduction ENS Access Protection or Exploit Prevention, MVISION Insights recommendations
Multi-layered detection ENS Exploit Prevention, MVISION Insights telemetry, MVISION EDR Tracing, ATD file analysis
Sandboxing and threat analysis ATD file analysis
Rule & Risk-based analytics MVISION EDR tracing
Containment ENS Dynamic Application Containment
Defense Evasion Attack surface reduction ENS Access Protection and Exploit Prevention, MVISION Insights recommendations
Multi-layered detection ENS Exploit Prevention, MVISION Insights telemetry, MVISION EDR Tracing, ATD file analysis
Sandboxing and threat analysis ATD file analysis
Rule & Risk-based analytics MVISION EDR tracing
Containment ENS Dynamic Application Containment
Discovery Attack surface reduction ENS Access Protection and Exploit Prevention
Multi-layered detection ENS Exploit Prevention, MVISION EDR Tracing, ATD file analysis
Sandboxing and threat analysis ATD file analysis
Rule & Risk-based analytics MVISION EDR tracing
Command & Control Attack surface reduction MVISION Insights recommendations
Multi-layered detection ENS Firewall IP Reputation, MVISION Insights telemetry, MVISION EDR Tracing, ATD file analysis
Multi-layered protection ENS Firewall
Rule & Risk-based analytics MVISION EDR tracing
Containment ENS Firewall and Dynamic Application Containment
Impact Multi-layered detection MVISION EDR tracing, ATD file analysis
Rule & Risk-based analytics MVISION EDR tracing
Containment ENS Dynamic Application Containment
Advanced remediation ENS Advanced Rollback

A description of the McAfee Solutions is provided below. 

Now this allowed me to map the solutions from the McAfee portfolio to each capability, and with that indirectly to the MITRE tactics. But I did not want to end here, as different tools might take a different role in the defensive architecture. For example, MVISION Insights can give you details around your current configuration and automatically overlays it with the current threat campaigns in the wild, giving you the ability to proactively prepare and harden your systems. Another example would be using McAfee Endpoint Security (ENS) to block all unsigned PowerShell scripts, effectively reducing the risk of being hit by a file-less malware based on this technology to nearly 0%. On the other end of the scale, solutions like MVISION EDR will give you great visibility of actions that have occurred, but this happens after the fact, so there is a high chance that you will have some cleaning up to do. This brings me to the topic of “improving protection before moving into detection” but this is for another blog post.

Coming back to the mapping shown above, let us quickly do…

Reality Check 2: Does this mapping feel accurate too?

For me it does, and here is why:

  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 3rd-party tools. It also goes the other way around as ATD allows other security controls to forward files for analysis in our sandbox, but this might be a topic for another blog post.

All the items listed above can be acquired by licensing our MVISION Premium suite in combination with McAfee ATD.

Based on the components and the mapping to the capabilities, I was also able to create a graph based on our most common device security bundles and their respective malware defense score:

In the graph above you can see four of our most sold bundles, ranging from the basic MVISION Standard, up to MVISION Premium in combination with McAfee Advanced Threat Defense (ATD). The line shows the ransomware detection & protection score, steadily rising as you go from left to right. Interestingly, the cost per point, i.e. how much dollar you need to spend to get one point, is much lower when buying the largest option in comparison to the smaller ones. As the absolute cost varies on too many variables, I have omitted an example here. Contact your local sales representative to gather an estimated calculation for your environment.

So, have I come to this conclusion by accident? Let us find out in the last installment of the reality check:

Reality Check 3:  Is this security architecture well suited for today’s threats?

For me it does, and here is why:

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

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

By: Sam Quinn
22 March 2021 at 04:01

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

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

16 March 2021 at 13:00
how to run a virus scan

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 GermanVietnamese 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 Blog.

McAfee Defender’s Blog: Operation Dianxun

16 March 2021 at 13:00

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

Seven Windows Wonders – Critical Vulnerabilities in DNS Dynamic Updates

9 March 2021 at 18:13
how to run a virus scan

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

McAfee ATR Thinks in Graphs

8 March 2021 at 11:00

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

Ripple20 Vulnerability Mitigation Best Practices

22 June 2020 at 22:32

On June 16th, the Department of Homeland Security and CISA ICS-CERT issued a critical security advisory warning covering multiple newly discovered vulnerabilities affecting Internet-connected devices manufactured by multiple vendors. This set of 19 vulnerabilities in a low-level TCP/IP software library developed by Treck has been dubbed “Ripple20” by researchers from JSOF.

A networking stack is a software component that provides network connectivity over the standard internet protocols. In this specific case these protocols include ARP, IP (versions 4 and 6), ICMPv4, UDP and TCP communications protocols, as well as the DNS and DHCP application protocols. The Treck networking stack is used across a broad range of industries (medical, government, academia, utilities, etc.), from a broad range of device manufacturers – a fact which enhances their impact and scope, as each manufacturer needs to push an update for their devices independently of all others. In other words, the impact ripples out across the industry due to complexities in the supply and design chains.

Identifying vulnerable devices on your network is a crucial step in assessing the risk of Ripple20 to your organization. While a simple Shodan search for “treck” shows approximately 1000 devices, which are highly likely to be internet-facing vulnerable devices, this represents only a fraction of the impacted devices. Identification of the Treck networking stack vs. other networking stacks (such as the native Linux or Windows stacks) requires detailed analysis and fingerprinting techniques based on the results of network scans of the devices in question.

The impact of these vulnerabilities ranges from denial of service to full remote code exploitation over the internet, with at least one case not requiring any authentication (CVE-2020-11901). JSOF researchers identified that these vulnerabilities impact a combination of traditional and IoT devices. Customers should review advisories from vendors such as Intel and HP because non-IoT devices may be running firmware that makes use of the Treck networking stack.

Ripple20’s most significant impact is to devices whose network stack is exposed (in general IoT devices incorporating the Treck network stack) as compared to devices that incorporate the stack that it is only exposed to the local device. We recommend that you audit all network-enabled devices to determine if they are susceptible to these vulnerabilities.

There are potentially tens of millions of devices that are vulnerable to at least one of the Ripple20 flaws. Mitigating impact requires attention from both device owners and device vendors.

Mitigations for users of vulnerable devices per CISA recommendations (where possible): 

  • Patch any device for which a vendor has released an update.
  • Practice the principle of least privilege for all users and devices (devices and users should only have access to the set of capabilities needed to accomplish their job). In this case, minimize network exposure and internet-accessibility for all control system devices.
  • Locate control system networks and remote devices behind firewalls and isolate them from the business network.
  • When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that a VPN is only as secure as the connected devices. VPN solutions should use multi-factor authentication.
  • Use caching DNS servers in your organization, prohibiting direct DNS queries to the internet. Ideally, caching DNS servers should utilize DNS-over-HTTPS for lookups.
  • Block anomalous IP traffic by utilizing a combination of firewalls and intrusion prevention systems.

Where Can I Go to Get More Information?

Please review KB93020 for more information and subscribe for updates.

The post Ripple20 Vulnerability Mitigation Best Practices appeared first on McAfee Blog.

What’s in the Box? Part II: Hacking the iParcelBox

18 June 2020 at 07:01

Package delivery is just one of those things we take for granted these days. This is especially true in the age of Coronavirus, where e-commerce and at-home deliveries make up a growing portion of consumer buying habits.

In 2019, McAfee Advanced Threat Research (ATR) conducted a vulnerability research project on a secure home package delivery product, known as BoxLock. The corresponding blog can be found here and highlights a vulnerability we found in the Bluetooth Low Energy (BLE) configuration used by the device. Ultimately, the flaw allowed us to unlock any BoxLock in Bluetooth range with a standard app from the Apple or Google store.

Shortly after we released this blog, a similar product company based in the UK reached out to the primary researcher (Sam Quinn) here at McAfee ATR, requesting that the team perform research analysis on his product, called the iParcelBox. This device is comprised of a secure steel container with a push-button on the outside, allowing for package couriers to request access to the delivery container with a simple button press, notifying the homeowner via the app and allowing remote open/close functions.

iParcelBox – Secure Package Delivery & iParcelBox App

The researcher was able to take a unique spin on this project by performing OSINT (Open Source Intelligence), which is the practice of using publicly available information, often unintentionally publicized, to compromise a device, system or user. In this case, the primary developer for the product wasn’t practicing secure data hygiene for his online posts, which allowed the researcher to discover information that dramatically shortened what would have been a much more complicated project. He discovered administrative credentials and corresponding internal design and configurations, effectively providing the team access to any and all iParcelBox devices worldwide, including the ability to unlock any device at a whim. All test cases were executed on lab devices owned by the team or approved by iParcelBox. Further details of the entire research process can be found in the full technical version of the research blog here.

The actual internals of the system were well-designed from a security perspective, utilizing concepts like SSL for encryption, disabling hardware debugging, and performing proper authentication checks. Unfortunately, this level of design and security were all undermined by the simple fact that credentials were not properly protected online. Armed with these credentials the researcher was able to extract sensitive certificates, keys, device passwords, and WIFI passwords off any iParcelBox.

Secondly, as the researcher prepared the writeup on the OSINT techniques used for this, he made a further discovery. When analyzing the configuration used by the Android app to interact with the cloud-based IOT framework (AWS-IOT), he found that even without an administrative password, he could leak plaintext temporary credentials to query the AWS database. These credentials had a permission misconfiguration which allowed the researcher to query all the information about any iParcelBox device and to become the primary owner.

In both cases, to target a device, an attacker would need to know the MAC address of the victim’s iParcelBox; however, the iParcelBox MAC addresses appeared to be generated non-randomly and were simple to guess.

A typical research effort for McAfee ATR involves complex hardware analysis, reverse engineering, exploit development and much more. While the developer made some high-level mistakes regarding configuration and data hygiene, we want to take a moment to recognize the level of effort put into both physical and digital security. iParcelBox implemented numerous security concepts that are uncommon for IOT devices and significantly raise the bar for attackers. It’s much easier to fix issues like leaked passwords or basic configuration issues than to rebuild hardware or reprogram software to bolt on security after the fact. This may be why the company was able to fix both issues almost immediately after we informed them in March of 2020. We’re thrilled to see more and more companies of all sizes embracing the security research community and collaborating quickly to improve their products, even from the beginning of the development cycle.

What can be done?

For consumers:

Even developers are subject to the same issues we all have; choosing secure and complex passwords, protecting important credentials, practicing security hygiene, and choosing secure configurations when implementing controls for a device. As always, we encourage you to evaluate the vendor’s approach to security. Do they embrace and encourage vulnerability research on their products? How quick are they to implement fixes and are they done correctly? Nearly every product on the market will have security flaws if you look hard enough, but the way they are handled is arguably more important than the flaws themselves.

For developers and vendors:

This case study should provide a valuable testament to the power of community. Don’t be afraid to engage security researchers and embrace the discovery of vulnerabilities. The more critical the finding, the better! Work with researchers or research companies that practice responsible disclosure, such as McAfee ATR. Additionally, it can be easy to overlook the simple things such as the unintentional leak of critical data found during this project. A security checklist should include both complex and simple steps to ensure the product maintains proper security controls and essential data is protected and periodically audited.

The post What’s in the Box? Part II: Hacking the iParcelBox appeared first on McAfee Blog.

My Adventures Hacking the iParcelBox

By: Sam Quinn
18 June 2020 at 07:01

In 2019, McAfee Advanced Threat Research (ATR) disclosed a vulnerability in a product called BoxLock. Sometime after this, the CEO of iParcelBox, a U.K. company, reached out to us and offered to send a few of their products to test. While this isn’t the typical M.O. for our research we applaud the company for being proactive in their security efforts and so, as the team over at iParcelBox were kind enough to get everything shipped over to us, we decided to take a look.

The iParcelBox is a large steel box that package couriers, neighbors, etc. can access to retrieve or deliver items securely without needing to enter your home. The iParcelBox has a single button on it that when pushed will notify the owner that someone wants to place an object inside. The owner will get an “open” request push notification on their mobile device, which they can either accept or deny.

The iParcelBox (Photo Credit: iparcelbox.com)

Recon

The first thing we noticed about this device is the simplicity of it. In the mindset of an attacker, we are always looking at a wide variety of attack vectors. This device only has three external vectors: remote cloud APIs, WIFI, and a single physical button.

iParcelBox Delivery Button (Photo Credit: iparcelbox.com)

During setup the iParcelBox creates a WIFI access point for the mobile application to connect with and send setup information. Each iParcelBox has a unique randomly generated 16-character WiFi password that makes brute forcing the WPA2 key out of the question; additionally, this Access Point is only available when the iParcelBox is in setup mode. The iParcelBox can be placed into setup mode by holding the button down but it will warn the owner via a notification and will only remain in setup mode for a few minutes before returning to normal operation.

iParcelBox Random WiFi Access Point Password (16 Characters)

Since we have the WiFi password for the iParcelBox in our lab, we connected to the device to see what we could glean from the webserver. The device was only listening on port 443, meaning that the traffic between the application and iParcelBox was most likely encrypted, which we later verified. This pointed us to the Android app to try to decipher what type of messages were being sent to the iParcelBox during setup.

iParcelBox Port Scan

Using dex2jar we were able to disassemble the APK file and look at the code within the app. We noticed quickly that the iParcelBox was using MQTT (MQ Telemetry Transport) for passing messages back and forth between the iParcelBox and the cloud. MQTT is a publish/subscribe message protocol where devices can subscribe to “topics” and receive messages. A simple description can be found here: (https://youtu.be/EIxdz-2rhLs)

Dex2Jar Command

A typical next step is to retrieve the firmware for the device, so we started to look through the disassembled APK code for interesting URLs. While we didn’t find any direct firmware links, we were able to find some useful information.

Disassembled Code pulled from APK

The code snipped above shows a few interesting points, including the string “config.iparcelbox.com” as well as the line with “app” and “TBpwkjoU68M”. We thought that this could be credentials for an app user passed to the iParcelBox during setup; however, we’ll come back to this later. The URL didn’t resolve on the internet, but when connecting to the iParcelBox access point and doing a Dig query we were able to see that it resolves to the iParcelBox.

DNS Lookup of config.iparcelbox.com

Nothing from the Android app or the webserver on the device popped out to us so we decided to look deeper. One of the most common ways that information about targets can be gathered is by looking through user forums and seeing if there are others trying to tweak and modify the device. Often with IOT devices, home automation forums have numerous examples of API usage as well as user scripts to interact with such devices. We wanted to see if there was anything like this for the iParcelBox. Our initial search for iParcelBox came up empty, other than some marketing content, but when the search was changed to iParcelBox API, we noticed a few interesting posts.

Google Search for “iparcelbox api”

We could see that even on the first page there are a few bug reports and a couple of user forums for “Mongoose-OS”. After going to the Mongoose-OS forums we could clearly see that one user was a part of the iParcelBox development team. This gave us some insight that the device was running Mongoose-OS on an ESP32 Development board, which is important since an ESP32 device can be flashed with many other types of code. We started to track the user’s posts and were able to discover extensive information about the device and the development decisions throughout the building process. Most importantly this served as a shortcut to many of the remaining analysis techniques.

As mentioned earlier, a high priority is to try to gain access to the device’s firmware by either pulling it from the device directly or by downloading it from the vendor’s site. Pulling firmware is slightly more tedious since you must often solder wires to the flash chip or remove the chip all-together to interface with the flash. Before we began to attempt to pull the firmware from the ESP32, we noticed another post within the forums that mentioned that the flash memory on the device was encrypted.

Post describing flash encryption

With this knowledge, we skipped soldering wires to the ESP32 and didn’t even try to pull the firmware manually since it would have proven difficult to get anything off it. This also gave us insight into the provisioning process and how each device is set up. With this knowledge we started to look for how the OTA updates are downloaded.

Searching around a little longer we were able to find a file upload of a large log file containing what seemed like the iParcelBox boot procedure. Searching through the log we found some highly sensitive data.

Admin Credentials and gh-token from boot log

In the snippet above you can see that the admin credentials are passed as well as the GitHub token. Needless to say, this isn’t good practice, we will see if we can use that later. But in this log, we also found a firmware URL.

Firmware URL from boot log

However, the URL required a username and password.

Firmware.iparcelbox.com .htaccess

We found this forum post where “.htaccess” is set up to prevent unintended access to the firmware download.

.htaccess post

The admin password found earlier didn’t authenticate, so we wanted to get the logs off the device to see if these were old credentials and if we could print the new credentials out to UART.

The internals of the iParcelBox (TX and RX highlighted in red)

The ESP32 RX and TX pins are mapped to the USB-C connection, but if you look at the circuit there is no FTDI (Future Technology Devices International) chip to do processing, so this is just raw serial. We decided to just solder to the vias (Vertical Interconnect Access) highlighted in red above, but still no data was transferred.

Then we started to search those overly helpful forum postings again, and quickly found the reason.

Disable UART

This at least verified that it wasn’t something that we set up incorrectly, but rather that logging was simply disabled over UART.

Method #1 – RPC

From our recon work we pretty much settled on the fact that we were not going to get into the iParcelBox easily from a physical standpoint and decided to switch a network approach. We knew that during setup the iParcelBox creates a wireless AP and that we can connect to it. Armed with our knowledge from the forums we decided to revisit the web server on the iParcelBox. We began by sending some “MOS” (Mongoose-OS) control commands to see what stuck.

Setup instructions for Mongoose-OS can be found here. Instead of installing directly to the OS we did it in Docker for portability.

Docker file used to create mos

Referencing the forums provided several examples of how to use the mos command.

Docker mos commands

The first command returned a promising message that we just need to supply credentials. Remember when we found the boot log earlier? Yep, the admin credentials were posted online, and they actually work!

At this point we had full effective root access to the iParcelBox including access to all the files, JavaScript code, and even more importantly, the AWS certificate and private key.

With the files extracted from the device we noticed that the developers at iParcelBox implemented an Access Control List (ACL). For an IOT device this is uncommon but a good practice.

ACL showing users permissions

The credentials we found earlier in the disassembled Android APK with the username “app” were RPC credentials but with limited permissions to only run Sys.GetInfo, Wifi.Scan, Wifi.PortalSave and Sys.Reboot. Nothing too interesting can be done with those credentials, so for the rest of this method we will stick with the “admin” credentials.

Now that we have the credentials, certificates, and private keys we wanted to try to pivot to other devices. During setup we noticed that the MAC address was labeled “TopicID.”

Setup process linking MAC Address to the TopicID

As we determined earlier, the iParcelBox uses MQTT for brokering the communication between the device, cloud, and mobile application. We were interested to find out if there were any authentication barriers in place, or if all you need is the MAC address of the device to initiate commands remotely.

Since we essentially had root access, enabling logging was a logical next step so we could see what was happening on the device. From one of the Mongoose-OS forums posts we saw that you can enable UDP logging to a local device by changing the configuration on the iParcelBox.

How to enable UDP logging post

We provisioned the iParcelBox, then held the button down until we entered setup mode (where the AP was available), thus reenabling RPC calls. Then we set the “udp_log_addr” to our local machine.

Reenabling Logging on iParcelBox

Now we have logs and much more information. We wanted to test if we could access the MQTT broker and modify other iParcelBoxes. In the logs we were able to validate that the MQTT broker was setup on AWS IOT and was using the certificate and keys that we pulled earlier. We found some Python examples of connecting to the AWS MQTT broker (https://github.com/aws/aws-iot-device-sdk-python) but it assumed it knows the full topic path (e.g. topic_id/command/unlock).

UDP Log file

Parsing through the extracted logs from UDP, we were able to find the format for the “shadow/update” MQTT topic. However, when trying to subscribe to it with the Python script, it seemed to connect to the MQTT broker, but we couldn’t ever get any messages to send or receive. Our best guess is that it was limited to one subscribe per topic or that our code was broken.

We went searching for another way to control devices. This brought us back to the Mongoose-OS forum (seeing a pattern here?). We found this post explaining that the devices can run RPC commands over MQTT.

RPC over MQTT

This would be better for an attacker than only MQTT access, since this gives full access to the device including certificates, keys, user configuration files, WIFI passwords, and more. We could also use RPC to write custom code or custom firmware at this point.  We found the official Mongoose-OS support for this here (https://github.com/mongoose-os-libs/rpc-mqtt), to which they even included an example with AWS IOT.

After plugging that into the “mos” command we were able to run all administrative RPC commands on the device that we pulled the keys from, but also any other device that we knew the MAC address of.

Running RPC commands on multiple ATR lab devices

From looking at the two iParcelBoxes that were sent to us, the MAC addresses are only slightly different and strongly suggest that they are probably generated incrementally.

  • 30AEA4C59D30
  • 30AEA4C59D6C

Theoretically, with the MAC addresses incremental we could have just written a simple script to iterate through each of the iParcelBoxes’ MAC addresses, found any iParcelBox connected to the internet, and controlled or modified them in any way we wanted. However, the most common attack would likely be a more targeted one, where the attacker was looking to steal a package or even a victim’s home WiFi credentials. An attacker could do a simple network scan to find the MAC address of the target iParcelbox using a tool like “airodump-ng”. Then, after the attacker knows the target MAC address, they could use the admin credentials to initiate a “mos” command over MQTT and execute a “GPIO.Toggle” command directed at the GPIO (General Purpose Input Output) pin that controls the locking mechanism on the iParcelBox. A toggle will invert the state, so if the iParcelBox is locked, a GPIO toggle will unlock the box. If the attacker had other motives, they could also initiate a config dump to gain access to the WiFi credentials to which the iParcelBox is connected.

Scanning for iParcelBoxes and Controlling them with RPC

Method #2 – AWS Misconfiguration

While writing this blog we wanted to double check that SSL pinning was done properly. After we saw this post during our recon, we assumed it was pinning a certificate. We set up an Android with a certificate unpinner using Frida.  With the unpinner installed and working we were able to decrypt traffic between the application and the AWS servers, but it failed to decrypt the data from application to the iParcelBox. Please follow this technique if you’d like to learn how you can unpin certificates on Android devices.

Next, we reran the iParcelBox application without the Frida SSL Unpinner, which returned the same AWS server transactions, meaning that pinning wasn’t enabled. We browsed through some of the captures and found some interesting requests.

Cognito Credential SSL Network Capture

The “credentials” in the capture immediately piqued our interest. They are returned by a service called “Cognito”, which is an AWS service allowing apps and users to access resources within the AWS ecosystem for short periods of time and with limited access to private resources.

AWS Cognito example (Photo Credit: Amazon.com)

When an application wants to access an AWS service, it can ask for temporary credentials for the specific task. If the permissions are configured correctly, the credentials issued by the Cognito service will allow the application or user to complete that one task and deny all other uses of the credentials to other services.

To use these credentials, we needed the AWS-CLI interface. Thankfully, Amazon even has a Docker image for AWS-CLI which made things much easier for us. We just saved the credentials returned from the Cognito service inside of a “~/.aws” folder. Then we checked what role these credentials were given.

AWS-CLI docker command

The credentials captured from the Android application were given the “AppAuth_Role”. To find out what the “AppAuth_Role” had access to we then ran a cloud service enumeration using the credentials; the scripts can be found here (https://github.com/NotSoSecure/cloud-service-enum) and are provided by the NotSoSecure team. The AWS script didn’t find any significant security holes and showed that the credentials were properly secured. However, looking at the next few network captures we noticed that these credentials were being used to access the DynamoDB database.

Checking if the user is subscribed to the Premium service

Getting the owner’s devices

After reading through some of the DynamoDB documentation we were able to craft database queries.

DynamoDB Query

Because the “primary key” for the database is the “DeviceID” which we know is just the MAC address of the iParcelBox, we can then modify this query and get any other device’s database entries. While we didn’t test this for ethical reasons, we suspect that we could have used this information to gain access to the MQTT services. We also did not attempt to write to the database since this was a live production database and we didn’t want to corrupt any data.

We investigated the Android application attempting to trigger some more database interactions to see what other queries were being sent, but were limited to the following:

  • Accounts – Shows premium subscription info
  • Owners – Shows devices and guests of each iParcelBox
  • Users – Used to save owners of each iParcelBox (only during setup)

With our self-imposed database write restrictions, none of these tables really helped us anyway. That is when we began looking at the disassembled code of the Android app for more clues. Since we now knew the table names, we searched for “ClientID”, which turned up the Java file “DBConstants.class.”

Constants file from APK

This constants file gave us information that there are more database tables and fields, even though we never saw them in the network traffic. The “TABLE_DEVICES_PASSWORD” caught our eyes from the “iParcelBox_devices” table.

We tested the “AppAuth_Role” credentials on this table as well, which was accepted.

Requesting information from the iParcelBox_devices table

We were able to get the device password and serial number all from the MAC address. Recall the “iParcelBox Setup Information” image at the beginning of the blog and how it mentions that you should keep this information safe. The reason that this information should be kept safe is that you can become the owner of the iParcelBox if you know the MAC address, serial number, and password even without the QR code thanks to the “Add Manually” button.

“Add manually” option during setup

With this information an attacker could register for a new iParcelBox account, login to the application, capture the Cognito credentials, begin the “setup” process, click “Add Manually” and then enter all the required information returned from the database to gain full control over any iParcelBox. This could all take place from simply knowing the MAC address since the “AppAuth_Role” can read any database entry.

Required Information to set up the iParcelBox

Lessons Learned

This project took a turn from a classic hardware/IOT device research project to an OSINT research topic very early on. It really goes to show that even simple mistakes with online data hygiene could expose key details to attackers allowing them to narrow down attack vectors or expose sensitive information like credentials.

Since this was a sponsored project from iParcelBox, we reported this to the company immediately. They promptly changed the admin password for every iParcelBox and asked the developers at Mongoose-OS to implement a change where one device’s AWS certificate and private key cannot control any other device. This was patched within 12 hours after our vendor disclosure, which puts iParcelBox in the top response time for a patch that we have ever seen. We have tested the patch and can no longer control other devices or use the old admin password to access the devices from within setup mode.

iParcelBox also fixed the Android application not pinning certificates properly and removed all direct calls to the DynamoDB. We were still able to decrypt some traffic using the Frida SSL unpinner, but the application would freeze, which we believe is due to the MQTT broker not accepting a custom certificate. The DynamoDB queries are now wrapped in API calls which also check against the customer ID. This prevents someone from using their extracted Cognito credentials to obtain information from any device other than their own. Wrapping the database queries within API calls is an effective security fix as well, as the data can be parsed, verified, and sanitized all before committing to the database.

We wanted to give props to the team at iParcelBox for their focus on security throughout the development of this product. It is easy to see from the device and the forum posts that the developers have been trying to make this device secure from the start and have done it well. All non-essential features like UART and Bluetooth are turned off by default and a focus on data protection is clearly there as evidenced through the use of SSL and encryption of the flash memory. There are not many attack surfaces that an attacker could leverage from the device and is a great refreshment to see IOT devices heading this direction.

The post My Adventures Hacking the iParcelBox appeared first on McAfee Blog.

RagnarLocker Ransomware Threatens to Release Confidential Information

9 June 2020 at 16:21
Ransomware

EXECUTIVE SUMMARY

The RagnarLocker ransomware first appeared in the wild at the end of December 2019 as part of a campaign against compromised networks targeted by its operators.

The ransomware code is small (only 48kb after the protection in its custom packer is removed) and coded in a high programming language (C/C++). Like all ransomware, the goal of this malware is to encrypt all files that it can and request a ransom for decrypting them.

RagnarLocker’s operators, as we have seen with other bad actors recently, threaten to publish the information they get from compromised machines if ransoms are not paid.

After conducting reconnaissance, the ransomware operators enter the victim’s network and, in some pre-deployment stages, steal information before finally dropping the ransomware that will encrypt all files in the victim’s machines.

The most notable RagnarLocker attack to date saw this malware deployed in a large company where the malware operators then requested a ransom of close to $11 million USD in return for not leaking information stolen from the company. In this report we will talk about the sample used in this attack.

At the time of writing there are no free decryptors for RagnarLocker.

However, certain McAfee products, including personal antivirus, endpoint, and gateway can protect our customers against the threats that we talk about in this report.

RAGNARLOCKER OVERVIEW

The unpacked malware is a binary file of 32 bits that can be found as an EXE file.

FIGURE 1. INFORMATION ABOUT THE MALWARE

As can be seen in the previous screenshot, this sample was compiled on the 6th of April 2020. The attack mentioned earlier took place some days later, but this sample was prepared for the victim, as we will explain later.

Name malware.exe
Size 48,460 bytes unpacked (can change between samples), packed can be variable
File-Type EXE 32 bits (can change between samples)
SHA 256 7af61ce420051640c50b0e73e718dd8c55dddfcb58917a3bead9d3ece2f3e929
SHA 1 60747604d54a18c4e4dc1a2c209e77a793e64dde
Compile time 06-04-2020 (can change between samples)

 

TECHNICAL DETAILS

As we often see with ransomware, RagnarLocker starts preparing some strings of languages for the CIS countries that are embedded within its own code (in Unicode).

FIGURE 2. THE LANGUAGE STRINGS EMBEDDED INTO THE CODE IN THE STACK

The languages that are hardcoded are:

Georgian
Russian
Ukrainian
Moldavian
Belorussian
Azerbaijani
Turkmen
Kyrgyz
Kazakh
Uzbek
Tajik

 

After preparing these strings, the malware uses the function “GetLocaleInfoW” to get the LOCALE_SYSTEM_DEFAULT language as a string. Once obtained, it will check the system language with the blacklisted languages and, if any of them match, it will terminate itself with the function “TerminateProcess” and with an error result code of 0x29A (as we have seen before with many different malware samples).

FIGURE 3. CHECK OF THE LANGUAGE AGAINST THE BLACKLIST

The check against the LOCALE_SYSTEM_DEFAULT is to prevent a user from installing a language they would not otherwise use as a means of avoiding infection. The check is made against the language selected in Windows. Of course, not everyone in these countries will be using a CIS language in Windows so English is also ok to use. As with other ransomware families, there is no guarantee that infection will be avoided if other languages are selected as the default.

After this the malware will get the name of the infected computer with the function “GetComputerNameW” and the username of whoever is actively using the machine at that time with the function “GetUserNameW”.

FIGURE 4. GET THE COMPUTER NAME AND THE USERNAME

After this the malware will read two registry keys:

  • HKLM\SOFTWARE\Microsoft\Cryptography and the subkey MachineGuid to get the GUID of the victim machine.
  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion and the subkey “ProductName” to get the name of the operating system.

For this the malware uses the functions “RegOpenKeyExW”, “RegQueryValueExW” and “RegCloseKey” in the hive HKEY_LOCAL_MACHINE. This hive can be read without admin rights.

FIGURE 5. READ FROM THE REGISTRY THE NAME OF OPERATING SYSTEM AND GUID

Next, RagnarLocker will prepare the first string in the stack with the function “lstrcpyW” and later will start joining the strings with the function “lstrcatW”.

The sequence is first the GUID of the machine, then the Windows operating system name, the user logged in the machine and, finally, the name of the victim machine.

FIGURE 6. GET INFORMATION OF THE USER AND MACHINE AND JOIN ALL STRINGS

In the screenshot some values were modified to protect my virtual machine. After getting this information and preparing the string, the malware makes a custom hash with each.

For this, the malware will reserve some memory with “VirtualAlloc” and get the size of the string and compute the hash in a very small loop. After this it will format the hash with the function “wsprintfW” to have it as a Unicode string.

FIGURE 7. MAKE THE CUSTOM HASH AND FORMAT AS UNICODE STRING

The hashes are made in the following order:

  • Machine name (g. 0xf843256f*)
  • Name of the user logged into the machine (e.g. 0x56ef3218*)
  • GUID of the infected machine (e.g. 0x78ef216f*)
  • Name of the operating system (e.g. 0x91fffe45*)
  • Finally, the full string with all strings joined (e.g. 0xe35d68fe*)

*The above values have been changed to protect my machine.

After this it will use the function “wsprintfW”, with the template string “%s-%s-%s-%s-%s”, to format the custom hashes together with hyphens between them, but in this case the hashes are in this order:

  • GUID
  • Operating System Name
  • Name of the logged in user
  • Name of the infected machine
  • Full string with all other strings joined together

FIGURE 8. CREATE CUSTOM HASH OF THE STRINGS AND FORMAT THE FINAL STRING IN A SPECIAL ORDER

The malware will get the command line of this launch process and will check if it has more than one argument (the first argument is always in C/C++) with the functions “GetCommandLineW”, to get the full command line with arguments if it exists, and “CommandLineToArgvW” to get the arguments if they exist.

If there is more than one argument the malware will avoid the next procedure. To keep the normal flow in the technical details section we will put what happens if only one argument exists. In this case the malware will try to make a Windows Event with the name of the formatted string with all hashes, as explained earlier (in our example case above, 78ef216f-91fffe45-56ef3218-f843256f-e35d68fe).

After trying to create the event the malware will check the last error with the function “GetLastError” and compare with ERROR_ALREADY_EXISTS (0xB7). If the event already exists the malware will check a counter with the value at 0x8000 (32768) and, if is not this value, it will increase the counter by one and try again to make the event, check the last error, and so on, until it can finally make the event, reach the counter value, or it reaches the maximum value in the counter (64233). If the event cannot be created the malware will get the pseudohandle to its own process with the function “GetCurrentProcess” and terminate it with the function “TerminateProcess” with the exit code 0x29A.

FIGURE 9. CREATE EVENT LOOP AFTER CHECKING THERE IS ONLY ONE ARGUMENT IN THE COMMAND LINE

This is done for several reasons:

  • The event is created to avoid relaunching another instance of the malware at the same time.
  • The check of the counter is made if another instance of the malware is launched, to wait for the previous one to finish before continuing the process (this avoids some issues with the malware checking for crypted files).
  • The check of the argument, as we will explain later, can be used to avoid the event behavior so the malware will always try to encrypt files. It is one of the reasons why a vaccine against this malware is useless if the malware operator executes the malware with an argument as simple as “1”.

After this, the malware will try to access in raw mode all units connected to the victim machine in a physical way, preparing the string “\\.\PHYSICALDRIVE%d”. This string will be formatted with the function “wsprintfW”, starting with the first unit that is 0 to a maximum of 16 in a loop. After the format, the malware will use “CreateFileW” and check that it does not return the error “ERROR_INVALID_HANDLE” (that means the unit cannot be accessed or that it does not exist). If this error is returned it will increase the counter and format the string with the new value of the counter. If it can open the handle to the unit in raw mode it will send two commands using the function “DeviceIoControl”.

The commands are:

  • 0x7C0F4 -> IOCTL_DISK_SET_DISK_ATTRIBUTES with the attributes of: DISK_ATTRIBUTE_READ_ONLY and DISK_ATTRIBUTE_OFFLINE.
  • 0x70140 -> IOCTL_DISK_UPDATE_PROPERTIES that will be make the drive update its partition table. As the attributes are updated the malware can be accessed in sharing mode on the disk.

FIGURE 10. CONTROL THE PHYSICAL DISK TO HAVE ACCESS TO IT

The ransomware’s next action is checking the units that exist and can be accessed without any problem. This can be done in two ways, the first of which is using the functions “FindFirstVolumeA”, “FindNextVolumeA” and “FindVolumeClose”.

FIGURE 11. GET VOLUME LETTER AND INFORMATION TO CHECK IT EXISTS AND CAN BE ACCESSED

The first two functions return the volume and the special internal value associated with it. This information comes from Windows, so the malware needs to translate it to the logic unit letter associated to this volume. This is done with the function “GetVolumePathNamesForVolumeNameA” that will return the logic letter associated to the volume inspected.

With this letter the function “GetVolumeInformationA” is then used to get information of the volume if it exists and is enabled. If the volume does not exist or cannot be checked the function will fail and the volume ignored, and the process will move onto the next volume in the machine.

Another check is made using the function “GetLogicalDrives” that will return a structure and, by checking one byte, the malware will know if the unit exists or not.

After this, the malware will prepare the keys that later will be needed to encrypt the files. To make them it will get the crypto context with the function “CryptAquireContextW” that will generate random data with “CryptGenRandom” and prepare to permutate this value with the SHA-512 algorithm. These values are the key and nonce of the Salsa20 algorithm that will be used later to encrypt files.

FIGURE 12. AQUIRE CRYPTO CONTEXT AND GENERATE SOME DATA AND PREPARE WITH SHA-512

The malware continues decrypting some strings using two steps, one in a big function for the first layer and the other that is used later for the second layer and the final string of the service. The services stopped are:

 

vss
sql
memtas -> associated with MailEnable
mepocs -> associated with MailEnable
Sophos -> associated with Sophos Antivirus
Veeam -> associated with a program to make backups and save in the cloud
Backup -> associated with Asus WebStorage
Pulseway -> associated with remote control software for IT departments
Logme -> associated with remote control software
Logmein -> associated with a remote control software
Conectwise -> associated with a remote control software
Splastop -> associated with a remote control software
Mysql -> associated with a program of databases
Dfs -> associated with the Distribute File System (Microsoft)

 

Please note: The services list can change between samples.

After decrypting the strings, the malware accesses the SCManager with the function “OpenSCManagerA”. If it does not want access it will ignore all services and continue onto the next step.

If it can open a handle to it, it will get the status of the service with the function “EnumServicesStatusA” and if the service is stopped already will pass to the next one. The malware calls this function two times, firstly to get the correct size needed for this function, with the last error being checked with ¨GetLastError¨ against the value 0xEA (ERROR_MORE_DATA) (that means that the application needs more memory to fill all information than the function gives).

FIGURE 13. OPEN THE SERVICE MANAGER AND ENUMSERVICESTATUS

This memory is reserved and the function called again later, in this case to get the real status and, if not stopped, the malware will open the service with the function “OpenServiceA” and query the status of the service with the function “QueryServiceStatusEx”. If the service is not stopped, it will get all dependencies of the service with “EnumDependentServicesA” and finally it will control the service to stop it with the function “ControlService”.

FIGURE 14. OPEN THE SERVICES AND CONTROL THEM

After this, the malware decrypts a list of the processes that it will try terminating if it finds them in the infected machine. For this decryption, the malware uses a string that converts into an integer and uses this integer as a critical value to decrypt the list.

For this task, the malware will create a snapshot of all processes in the system per this blacklist:

sql
mysql
veeam
oracle
ocssd
dbsnmp
synctime
agntsvc
isqlpussvc
xfssvccon
mydesktopqos
ocomm
dbeng50
sqbcoreservice
excel
infopath
msaccess
mspub
onenote
outlook
powerpnt
steam
thebat
thunderbird
visio
wordpad
winword
EduLink2SIMS
bengine
benetns
beserver
pvlsvr
beremote
VxLockdownServer
postgres
fdhost
WSSADMIN
wsstracing
OWSTIMER
dfssvc.exe
swc_service.exe
sophos
SAVAdminService
SavService.exe

 

Please note: The processes list can change between samples.

After making the snapshot it will enumerate all processes with the functions “Process32FirstW” and “Process32NextW” and for each process found will call the function “WideCharToMultyByte” to get the size needed to convert the name of the process returned in Unicode into Ascii. Later it reserves memory for the name and calls the same function to make the string conversion.

FIGURE 15. GET ALL SYSTEM PROCESSES

If the malware, after comparison with the function “StrStrIA”, detects some of the blacklisted processes it will open the process with the function “OpenProcess” and terminate it with the function “TerminateProcess” and with the exit  code of 0x29A.

FIGURE 16. OPEN THE PROCESS AND TERMINATE IT IF IT IS BLACKLISTED

The malware will check for all processes in the blacklist, using part of the string rather than the exact name. Not using the extension allows for greater obfuscation but carries the risk that some processes could be closed by accident if they share that string.

After this the malware will check if the operating system is 64-bit or not with the function “GetNativeSystemInfo” against the value 9 (that means that the OS is 64-bit).

If the operating system is 64-bit it will get, using “LoadLibraryW” and “GetProcAddress”, the function “Woe64EnableWow64FsRedirection” to remove the redirection that by default is found in 64-bit operating systems. This call is done in a dynamic way, but the malware does not check that the function was retrieved with success; usually it will be, but it is not 100% certain and a crash calling a null pointer could ensue.

FIGURE 17. CHECK THE OPERATING SYSTEM AND DISABLE REDIRECTION IF NEEDED

After this, the malware will prepare a string in Unicode embedded in the code with the string “wmic.exe shadowcopy delete” and will call it with the function “CreateProcessW”. After the call it will wait for up to an infinite amount of time using the function “WaitForSingleObject” so that the “wmic.exe” process can finish, irrespective of the size and number of shadow volumes, available machine resources, etc.

Of course, the malware will also use the typical program of “vssadmin” to delete the shadow volumes with the command “vssadmin delete shadows /all /quiet”, as well as with the function “CreateProcessW”. After that it will wait again with “WaitForSingleObject” for the end of the new process.

When it finishes, the malware will check again if the operating system is 64-bit and, if it is, will use “LoadLibraryW” and “GetProcAddress” to get the function “Wo64EnableWow64FsRedirection” to leave the system as before with the redirection. Again, the malware does not check that the function is resolved with success and calls it directly in a dynamic way.

FIGURE 18. DESTROY THE SHADOW VOLUMES AND RE-ENABLE THE REDIRECTION

While it seems like a mistake to destroy the shadow volumes again, it is not, as RagnarLocker has support for Windows XP and the WMIC classes do not exist in that operating system, hence the need to use the old program “vssadmin” that exists in both new and old operating systems.

The malware continues with the decryption of one PEM block encoded in base64 and the ransom note is prepared for the target in memory.

FIGURE 19. DECRYPTION OF THE PEM BLOCK AND THE RANSOM NOTE

An example of the ransom note, with confidential information removed, can be seen below:

FIGURE 20. EXAMPLE REDACTED RANSOM NOTE

After preparing both things the malware decodes the PEM block from the base64 as an object, getting a key that will be used to protect the keys used in the crypto process (of course this procedure may change in future samples as the malware evolves) of the RSA algorithm. It is important to note here that this RSA key changes per sample.

FIGURE 21. DECODE FROM BASE64 AND DECODE THE OBJECT AND IMPORT IT TO USE LATER

With this key it will encrypt the two random keys previously generated to protect them in memory. After that, the crypto will release the memory.

Later, it will get the name of the infected machine again, get the size of the name and will calculate the custom hash with the same algorithm as before.

FIGURE 22. CRYPT THE PREVIOUSLY GENERATED VALUES AND GET THE COMPUTER NAME

With this hash it will prepare a string with this structure:

  • RGNR_
  • hash from the name of the victim machine
  • the extension .txt
  • a backslash character at the start of the string

It is done with the function “lstrcatW”.

FIGURE 23. CREATION OF THE RANSOM NOTE NAME

With this string it will get the folder of “My Documents” for all users with the function “SHGetSpecialFolderPathW” (this function, based on the operating system, will get different paths for the documents). This string with the path of the folders will join with the string of the ransom note name and later make the final path to create the file.

FIGURE 24. GET THE DOCUMENTS FOLDER TO LATER WRITE THE RANSOM NOTE

After this it will encode in base64 the critical information to decrypt the files with the function “CryptBinaryToStringA”. The malware uses the function the first time to get the size needed and reserve memory and then uses it again to encode the data. After encoding the data, it creates the ransom note file in the documents path with the string previously joined with the path with the function “CreateFileW” and will write the contents of the ransom note that has been prepared in memory. Later, it will format a special string with some hardcoded characters with “—RAGNAR SECRET—” as a start of block and end of block and, between, will format the encode string in base64 and write in the ransom note.

FIGURE 25. CREATION OF THE RANSOM NOTE AND PUT THE RAGNAR SECRET AT THE END OF IT

Later, the malware will create a new string with the strings:

  • .ragnar_
  • hash of the name of the victim machine

This string will be used later as the new extension in the crypted files. After this the malware will enumerate again the logic units of the system with the function “GetLogicalDrivesW” and, to check if the unit is correct, will use the function “GetVolumeInformationW” and check the type of the unit and avoid the type of CD-ROM. For each logic unit it will enumerate all files and folders and will start the crypto process.

FIGURE 26. GET ALL LOGIC UNITS AND CHECK THEM

Before starting the crypto process, the malware will try to write the ransom note in the root of each unit that is found as a target.

The malware will ignore folders with these names:

Windows
Windows.old
Internet Explorer
Google
Opera
Opera Software
Mozilla
Mozilla Firefox
$Recycle.Bin
ProgramData
All Users

 

The ransom note will be written in all folders that are affected and, as with other ransomware, it will use the functions “FindFirstFileW” and “FindNextFileW” to enumerate all contents in each folder.

FIGURE 27. CHECK OF THE BLACKLISTED FOLDER NAMES

RagnarLocker also avoids crypting certain files:

autorun.inf
boot.ini
bootfont.bin
bootsect.bak
bootmgr
botmgr.efi
bootmgfw.efi
desktop.ini
iconcache.db
ntldr
ntuser.dat
ntuser.dat.log
ntuser.ini
thumbs.db
RGNR_<hash>.txt

 

 

FIGURE 28. CHECK OF BLACKLISTED FILE NAMES

If a file has one of these names it will be ignored and, if it has another name, the malware will avoid any file that has these extensions:

.db
.sys
.dll
.lnk
.msi
.drv
.exe

 

 

FIGURE 29. CHECK OF BLACKLISTED EXTENSIONS

These checks are in place to prevent the ransomware from destroying the operating system as the victim needs to have access to the machine to pay the ransom.

For each file that passes all controls a thread will be created that will encrypt it. After creating all threads, the malware will wait for up to an infinite amount of time with the function “WaitForMultipleObjects”.

In the crypto process, in the threads, the malware will check if the file has the mark “_RAGNAR_” at the end with the function “SetFilePointerEx” and by reading 9 bytes and checking if they are this string. If it has this mark the file will be ignored in the crypto process and will be renamed again (with an extension name based on the current machine name).

FIGURE 30. CHECK OF THE MARK OF CRYPTO IN THE FILE

In other cases the malware will encrypt the file and at the end of it will write the block crypted of the key, used in a block of 256 bytes, and the nonce used in another block of 256 bytes and, finally, the mark “_RAGNAR_”, along with one byte as NULL to end the string (that makes 9 bytes). The key and nonce used in the Salsa20 algorithm are encrypted by the RSA public key embedded in the malware. This ensures only the malware developers can have the RSA private key that belongs to the public key used to decrypt the key and nonce and, thus, decrypt the files in the system.

Before writing this information, the malware will use the function “LockFile” and, when the process of writing the function is finished, “UnlockFile” to release the file already crypted. This is done to prevent the file being changed or deleted during the encryption process.

FIGURE 31. WRITE THE NEW CONTENTS AT THE END OF THE FILE

After the crypto, or if the file is already crypted, the malware will change the extension to a new one, such as “.ragnar_45EF5632”.

FIGURE 32. CHANGE OF THE EXTENSION OF THE CRYPTED FILE

After all threads of crypto, the malware tries to get the session of the Terminal Services or the session of the user logged in the local machine with the function “WTSGetActiveConsoleSessionId”. With this session it gets the current process of the malware with the function “GetCurrentProcess” and the token of this process with the function “OpenProcessToken”. With the session that was got previously it tries to duplicate the token with the function “DuplicateTokenEx” and sets this token with the function “SetTokenInformation”. After this it will get the system directory with the function “GetSystemDirectoryW” and joins to this path the string “\notepad.exe”.

FIGURE 33. GET THE SESSION OF THE LOCAL USER OR TERMINAL SERVICES AND MANAGE THE TOKENS

With this prepared, the malware executes Notepad and, as an argument, the ransom note to show to the user what happened in the machine. The function used in this case is “CreateProcessAsUserW” to impersonate the user that had the session previously. Of course, this function is called with the desktop as “WinSta0\Default”.

FIGURE 34. CREATE A PROCESS OF THE NOTEPAD TO SHOW THE RANSOM NOTE

After this the malware finishes itself with the function “ExitProcess” and a code of exit of 0.

VACCINE

RagnarLocker can have a vaccine if a program is made that can make the event, as explained in the technical part of this blog. If this event exists, the malware does not make anything in the system, but this type of vaccine is not likely to offer a long-term solution for several reasons:

  • The way that the event is done, the malware developers can change the algorithm, or the order of the name of the event, or make a mutex instead of an event and the vaccine will stop working.
  • The algorithm has a hardcoded value. If this value is changed the final hash will be different and the vaccine becomes useless.
  • The malware is developed in such a way that if it has at least two arguments the event is not created so, if the operators want to execute with safety, they need only to execute with an argument, for example “<malware.exe> 1”.
  • The malware may evolve over time so the vaccine can be very fragile and limited.

For these reasons we think that a vaccine using this system is not helpful in the longer-term.

CONCLUSION

RagnarLocker is a simple ransomware, much like others that exist in the criminal market. Due to its small size, its operator’s aggressive behavior and the knowledge they seem to have that allows them to enter the networks of enterprises, as well as the threat to leak information if the ransom is not paid, RagnarLocker could potentially become a big threat in the future. Time will tell if RagnarLocker becomes a serious threat or disappears against a backdrop of other ransomware with more resources. The code is medium in quality.

COVERAGE

McAfee can protect against this threat in all its products, including personal antivirus, endpoint and gateway.

The names that it can have are:

  • Ransom-ragnar

Also, learn how Enhanced Remediation, a new capability in ENS 10.7, can automatically rollback changes made by processes that exhibit malicious behavior.

MITRE ATT&CK COVERAGE

  • Command and Control : Standard Application Layer Protocol
  • Defense Evasion : Disabling Security Tools
  • Discovery : Security Software Discovery
  • Discovery : Software Discovery
  • Discovery : System Information Discovery
  • Discovery : System Service Discovery
  • Discovery : System Time Discovery
  • Discovery : Query registry
  • Execution : Command-Line Interface
  • Execution : Execution through API
  • Exfiltration : Data Encrypted
  • Impact : Data Encrypted for Impact
  • Impact : Service Stop

YARA RULES

rule RagnarLocker

{

    /*

      This YARA rule detects the ransomware RagnarLocker in memory or unpacked in disk for the sample with hash SHA1 97f45184770693a91054075f8a45290d4d1fc06f and perhaps other samples

    */

    meta:

        author      = “McAfee ATR Team”

        description = “Rule to detect unpacked sample of RagnarLocker”

        version     = “1.0”

    strings:

        $a = { 42 81 F1 3C FF 01 AB 03 F1 8B C6 C1 C0 0D 2B F0 3B D7 }

    condition:

        $a

}

 

import “pe”

 

rule ragnarlocker_ransomware

{

   meta:

  

      description = “Rule to detect RagnarLocker samples”

      author = “Christiaan Beek | Marc Rivero | McAfee ATR Team”

      reference = “https://www.bleepingcomputer.com/news/security/ragnar-locker-ransomware-targets-msp-enterprise-support-tools/”

      date = “2020-04-15”

      hash1 = “63096f288f49b25d50f4aea52dc1fc00871b3927fa2a81fa0b0d752b261a3059”

      hash2 = “9bdd7f965d1c67396afb0a84c78b4d12118ff377db7efdca4a1340933120f376”

      hash3 = “ec35c76ad2c8192f09c02eca1f263b406163470ca8438d054db7adcf5bfc0597”

      hash4 = “9706a97ffa43a0258571def8912dc2b8bf1ee207676052ad1b9c16ca9953fc2c”

     

   strings:

  

      //—RAGNAR SECRET—

      $s1 = {2D 2D 2D 52 41 47 4E 41 52 20 53 45 43 52 45 54 2D 2D 2D}

      $s2 = { 66 ?? ?? ?? ?? ?? ?? 66 ?? ?? ?? B8 ?? ?? ?? ?? 0F 44 }

      $s3 = { 5? 8B ?? 5? 5? 8B ?? ?? 8B ?? 85 ?? 0F 84 }

      $s4 = { FF 1? ?? ?? ?? ?? 3D ?? ?? ?? ?? 0F 85 }

      $s5 = { 8D ?? ?? ?? ?? ?? 5? FF 7? ?? E8 ?? ?? ?? ?? 85 ?? 0F 85 }

     

      $op1 = { 0f 11 85 70 ff ff ff 8b b5 74 ff ff ff 0f 10 41 }

     

      $p0 = { 72 eb fe ff 55 8b ec 81 ec 00 01 00 00 53 56 57 }

      $p1 = { 60 be 00 00 41 00 8d be 00 10 ff ff 57 eb 0b 90 }

     

      $bp0 = { e8 b7 d2 ff ff ff b6 84 }

      $bp1 = { c7 85 7c ff ff ff 24 d2 00 00 8b 8d 7c ff ff ff }

      $bp2 = { 8d 85 7c ff ff ff 89 85 64 ff ff ff 8d 4d 84 89 }

     

   condition:

  

     uint16(0) == 0x5a4d and

     filesize < 100KB and

     (4 of ($s*) and $op1) or

     all of ($p*) and pe.imphash() == “9f611945f0fe0109fe728f39aad47024” or

     all of ($bp*) and pe.imphash() == “489a2424d7a14a26bfcfb006de3cd226”

}

 

IOCs

SHA256 7af61ce420051640c50b0e73e718dd8c55dddfcb58917a3bead9d3ece2f3e929
SHA256 c2bd70495630ed8279de0713a010e5e55f3da29323b59ef71401b12942ba52f6
SHA256 dd5d4cf9422b6e4514d49a3ec542cffb682be8a24079010cda689afbb44ac0f4
SHA256 63096f288f49b25d50f4aea52dc1fc00871b3927fa2a81fa0b0d752b261a3059
SHA256 b670441066ff868d06c682e5167b9dbc85b5323f3acfbbc044cabc0e5a594186
SHA256 68eb2d2d7866775d6bf106a914281491d23769a9eda88fc078328150b8432bb3
SHA256 1bf68d3d1b89e4f225c947442dc71a4793a3100465c95ae85ce6f7d987100ee1
SHA256 30dcc7a8ae98e52ee5547379048ca1fc90925e09a2a81c055021ba225c1d064c

 

USING MVISION EDR TO DETECT RAGNARLOCKER

With thanks to Mo Cashman and Filippo Sitzia

We downloaded a RagnarLocker sample from Virus Total to test detection capability by MVISION Endpoint Detection and Response (EDR). We tested first with the original sample which was known to most detection engines by this time. We then changed file hashes to test detection with an unknown sample. In both cases, MVISION EDR identified the suspicious behaviors and raised alerts. The original sample was detected as a HIGH Risk because the file had a known malicious reputation in McAfee Global Threat Intelligence which is integrated with MVISION EDR. The unknown samples were detected as Medium Risk and most likely would have triggered further inspection by a security analyst.

Sample VT submission

2020-05-30 13:30:55, File size: 48.50 KB, File type Win32 EXE, File name: omniga.exe, VT detections: 51/73

Test Environment

OS Win10, ENS 10.7 Threat Protection off, Adaptive Threat Protection off, MVISION EDR

Execution with original HASH – 3bc8ce79ee7043c9ad70698e3fc2013806244dc5112c8c8d465e96757b57b1e1

To further test MVISION EDR effectiveness, we modified the hash file slightly:

Execution with HASH changed – 63F5B6ED99C559341CF1AD081BAF55B4EACAD8E46D056764531BD316BF3C3EE3

Alerting Results for both samples

The post RagnarLocker Ransomware Threatens to Release Confidential Information appeared first on McAfee Blog.

OneDrive Phishing Awareness

By: Joy Olowo
8 June 2020 at 16:37

There are number of ways scammers use to target personal information and, currently, one example is, they are taking advantage of the fear around the virus pandemic, sending phishing and scam emails to Microsoft OneDrive users, trying to profit from Coronavirus/COVID-19. They will pretend to be emailing from government, consulting, or charitable organizations to steal victim’s OneDrive details. OneDrive scammers will steal sensitive account information like usernames and passwords.  We would like to educate McAfee users and the public about the potential risks with these scams.

Nefarious Groups Attempt to Harvest Users’ Credentials

Below we will take you through three examples of this kind of attack, coming from a government organization, consulting firm and a charitable organization hosted in OneDrive to make them appear more genuine to users. As the screenshot below illustrates, the goal is to steal the user’s OneDrive credentials.

Fake Government Email Baits Victims

Scammers pretend to be from government offices and deliver documents that contain the latest live questionnaire regarding COVID-19. Remember: governments do not generally email the masses, sending unrequested documents, so a user could verify by examining the sender email address and location in the email headers and could visit the legitimate government site to see if there is COVID-19 information there instead.

When the folder in the above image is clicked on, it redirects to the screenshot shown below.

A warning saying “Hmm… looks like this file doesn’t have a preview we can show you” baits the visitor into clicking on the Open button. When clicked, it takes them to the below OneDrive screenshot prompting them to enter their personal information.

Notice that the link points users to a vulnerable WordPress site that contains a credential phishing landing page. A user should be aware that a legitimate OneDrive login page will never be hosted on a non-Microsoft domain. This should be a red flag to the user that this may be a scam or phishing attack.

 

As intended by the scammers, the user cannot access the OneDrive document to view the updated government questionnaire and, instead, will receive an error message to try again later.

By this stage, the scammers would have already stolen the user’s OneDrive personal information.

Fake Consulting Firm Attempts to Trick Users with Secured Document

Scammers pretend to be a consulting firm to share a secured document with the customer regarding the COVID-19 pandemic. Accepting an email document from a random and unsolicited consulting firm should be regarded as suspicious.

 

 

If a recipient clicks on the Download PDF link, it will take them to the page shown above where they are prompted to login. If they do so, it brings them to the below Microsoft login page where they enter their email address and password.

After attempting to sign in, the victim will be presented with an error message, as seen in the below screenshot.

When they enter their OneDrive information they will receive an error message saying, “Sorry, but we’re having trouble signing you in”. However, by this point, the scammers have already stolen the user’s OneDrive information.

Fake Charitable Organization Tries to Trick Volunteers

Some emails appear like charitable organizations looking for volunteers to help the community.

 

If someone clicks on the open PDF link, it will take them to the below OneDrive login page.

Scammers are trying to harvest company and individual OneDrive credentials by pretending to appear as a non-profit organization looking for volunteers.

 

The user is then presented with a login screen requesting their credentials.

However, they should notice the URL hosting the OneDrive login page is not from a Microsoft domain and should be regarded as suspicious.

Advice to Consumers

Consumers should be aware of scammers trying to harvest OneDrive details and should follow these best practices: –

  • Be careful of any charity or businesses requesting their OneDrive user information. Stick with organizations known to be reputable.
  • Never share financial or personal information over the phone, via email or with untrusted sites.
  • Remember that legitimate organizations will almost never send an email asking for personal information.
  • Never click on suspicious links or download attachments from unknown sources.
  • Never log in to a web page reached through a link from an email.
  • Remember email addresses can be spoofed so if a message looks suspicious, contact the sender via a known telephone number taken from their official website.

Advice to Organizations

  • Organizations should activate multi-factor authentication to prevent stolen credentials from been used to access OneDrive or Office 365 accounts.
  • Ensure all employees are aware of the threat posed by OneDrive and Office 365 phishing scams and consider security awareness training where appropriate.

 

If you find suspected scam sites, please submit them to McAfee for review at https://trustedsource.org as well as reporting them to your local law enforcement.

The post OneDrive Phishing Awareness appeared first on McAfee Blog.

How To Use McAfee ATP to Protect Against Emotet, LemonDuck and PowerMiner

19 May 2020 at 16:30

Introduction

This blog describes how McAfee ATP (Adaptive Threat Protection) rules are used within McAfee Endpoint Security products. It will help you understand how ATP Rules work and how you can utilize them to prevent infections from prevalent malware families such as Emotet, LemonDuck and PowerMiner. Please read through the recommendation section to effectively utilize rules in your environment.

ATP rules are a form of Attack Surface reduction technology which detects suspicious use of OS features and applications. These rules target behaviors which are often abused by malware authors. There can be cases where legitimate applications utilize the same behavior and hence rules need to be configured based on the environment.

ATP rules within McAfee Endpoint Security (ENS) 10.5.3 and above have already detected over a million pieces of malware since the start of 2020. This blog will show you how to enable ATP rules and explains why they should be enabled by highlighting some of the malware we detect with them. We’ll also show you how to maximize detection capabilities by tweaking some specific settings.

First, let’s start with an overview. We release ATP rules in three types: Evaluate, DefaultOn and HighOn.

Evaluate rules are tested in the field by McAfee to determine if they are robust enough to detect malicious activity while not producing false positives. Once a rule has been in evaluate mode for a period of time, McAfee researchers will analyze its performance and either make modifications or promote it to DefaultOn or HighOn. ENS ATP customers connected to McAfee ePolicy Orchestrator (ePO) can manually change Evaluate rules to Enabled mode.

DefaultOn rules are created when McAfee has high confidence that no legitimate applications will be impacted. These rules are then enabled by default in all McAfee Endpoint Security rule groups.

HighOn rules detect behavior that is known to be malicious but may have some overlap with non-malicious applications. These rules are set to Observe mode for systems in the “Balanced” rule group, but act as DefaultOn for systems in the “Security” rule group. Later in this blog, we cover how to change the rule group in Endpoint Security products to enable HighOn rules.

How to enable ATP rules in ENS 10.5.3 and above

By default, many ATP rules are set to Observe mode. To enable these rules in an active-blocking mode, login to the ePO Console and go to Menu->Configuration->Server Settings.

 

Figure 1. Rules in the Balanced rule group.

Select Adaptive Threat Protection and select the required rule group (Productivity, Balanced, or Security).

As seen in Figure 1, Rule 329 is in Observe mode in the Balanced rule group and, in Figure 2 below, you can see it is Enabled by default in Security rule group.

Note: As mentioned previously, we analyze rules from time to time and make modifications so you may have different settings in your environment, depending upon the content version.

 

Figure 2. Rules in Security rule group.

To enable a rule click on Edit below the rules and Select the rule you would like to change, then select the desired state – Disabled, Enabled, or Observe. Figure 3. shows how we can change the state of Rule 256 which helps in detecting Emotet and Trickbot downloaders.

 

Figure 3. Changing the Rule State.

Click on Save and the rule should be enabled on the clients within a few minutes. Here you see that Rule 256 blocks malicious file JTI/Suspect.131328 by default.

Figure 4. Evaluate Rule blocking after Enabling.

Change the assigned rule group to use HighOn rules in ENS 10.5.3 and above

In this section, we will step through how you can change the rule group to “Security” which will enable all the HighOn rules in block mode by default. We recommend you check the logs to see if the HighOn rules have detected clean activity within your environments before changing to this rule group.

To change the rule group, login to the ePO console and go to Menu->Systems->System Tree

Figure 5. Selecting the group of systems to modify Policies for ENS.

Select a group and go to the Assigned Policies tab. Select ‘Endpoint Security Adaptive Threat Protection’ from the product dropdown.

Figure 6. Selecting policies to modify the assigned rule group.

Click on ‘My Default’ policy under the ‘Options’ category.

 

Figure 7. Changing the rule group to Security.

Scroll down to Rule Assignment. From the Rule Assignment drop-down list, select Security and click Save. This will update all the clients with ‘My Default’ policy to the Security rule group.

Enable HighOn rules in MVISION Endpoint  

To enable HighOn rules, MVISION Endpoint policy needs to be set to ‘High Protection’ if it is not already set by default. Follow these steps:

Login to the ePO console and go to Menu->Systems->System Tree

Figure 8. Selecting the group of systems to modify policies for MVISION Endpoint

Select a group and go to the Assigned Policies tab. Select ‘MVISION Endpoint’ from the product dropdown.

Figure 9. Selecting the policies to change the Protection mode.

Click on ‘Edit Assignment’ under General Category.

Figure 10. Changing MVISION Endpoint to High Protection.

Change ‘Inherit from’ to ‘Break Inheritance and assign the policy and settings below’. Also, change the ‘Assigned policy’ to ‘High Protection’ from the dropdown list and click on ‘Save’. This will enable all the HighOn rules.

ATP Rules in the Wild

This section highlights three prevalent threats which ATP rules detect. We highlight one rule for each DefaultOn/HighOn/Evaluate to demonstrate the importance of monitoring rule updates and enabling more aggressive rules if they are suitable for your environment.

PowerMiner (DefaultOn example)

The PowerMiner malware is a cryptocurrency malware that has been prevalent since 2019. We have discussed this malware before in a previous blog on AMSI detection. The purpose of PowerMiner is to infect as many machines as possible to mine Monero currency. The initial infection vector is via phishing emails which contain a batch file. Once run, this batch file will execute a malicious PowerShell script that will then begin the infection process.

ATP DefaultOn Rule 263 “Detect processes accessing suspicious URLs” and Rule 262 “Identify suspicious command parameter execution for Security rule group assignments” blocks this threat once PowerShell is executed by the Dropper.bat and it attempts to download the malicious PS1 file.

This is shown by the red cross in the flow chart above. As mentioned in the AMSI blog, this threat is also covered by our AMSI signatures but as we do with several threats, we have different forms of detection in case the malware authors modify their code to attempt to bypass one of them.

The IP Map below shows the detections of this threat between October 2019 and January 2020 by the ATP Rules mentioned above.

LemonDuck (HighOn example)

LemonDuck, like PowerMiner, is a coin mining malware. It spreads via various methods such as the Eternal Blue exploit and Mimikatz. Once a machine has been infected, LemonDuck will create several scheduled tasks to download various components which include the coin mining functionality. The flow chart below shows the Lemon Duck infection process:

 

ATP HighOn rule 329 “Identify and block suspicious usage of Scheduled Tasks in high change systems” blocks LemonDuck at the schedule task creation stage. Again, like PowerMiner, McAfee also has an AMSI signature which detects this threat as LemonDuck!<partial_hash>.

The IP Map below shows the detections of this threat between October 2019 and January 2020 by the ATP Rule mentioned above.

Emotet Downloader (Evaluate example)

Emotet is a Trojan which is responsible for downloading and executing several high-profile malwares including Trickbot, which is turn has been known to download and execute the Ryuk ransomware. Emotet is usually downloaded and executed on the victim’s machine by malicious documents which are sent out via email spam. The malicious document will use PowerShell to download the Emotet executable and execute it. The flow is shown below:

 

McAfee ATP rule 256 ‘Detect use of long -encoded command PowerShell’ and rule 264 ‘Inspect EncodedCommand Powershell’ will detect this behavior if enabled. This is not enabled by default as this behavior can be legitimate, so we recommend checking the detections in Evaluate mode and, if no false positives occur, then turning it on. This rule will also block other malware which performs the same activity as Trickbot. The IP Map below shows the detections Rule 256 has had between October 2019 and January 2020. This will include all threats detected by this rule, not just Emotet.

Recommendations

By now you are likely asking yourself which rules you should turn on. Firstly, it should be noted that enabling ATP Rules will have no performance impact however, as highlighted in the first section, they can sometimes cause false positives.

From the collection of ATP rules, we recommend turning on the ‘Observe’ mode rules mentioned in this blog.

In addition to the rules mentioned for each threat, the following rules can be turned to ‘Enabled’ mode from the EPO console as we described. As mentioned, there is continuous evaluation of these rules by McAfee researchers which can result in rules moving to a different rule group or merging into other existing rules.

  • Rule 238– Identify abuse of common processes spawned from non-standard locations.
  • Protection from files being executed from suspicious locations which are often used by attackers.
  • Rule 309 – Block processes attempting to launch from Office applications.
    • Office documents are the main vectors used to deploy malware. This rule prevents Office applications from being abused to deliver malicious payloads.
  • Rule 312 – Prevent email applications, such as Outlook, from spawning script editors and dual use tool
    • Spam emails are common initial attack vectors being utilized by malware authors. This rule will help to detect suspicious use of email applications by preventing the launch of uncommon processes.
  • Rule 323 – Prevent mshta from being launched as a child process.
    • Related to MITRE technique T1170. Mshta.exe is a utility that executes Microsoft HTML Applications (HTA). Attackers can use mshta.exe to execute malicious .hta files and JavaScript or VBScript. This rule will help to detect the malicious use cases. You can read more about mshta here.

In general, we recommend looking through your ATP logs and checking to see if any ‘Observe’ mode rules are causing detections. If you find any rules that are not detecting legitimate use cases, we advise changing them to ‘Enabled’ mode.

We advise using ePO groups for a small number of machines and then monitor the changed environment for any false positives. If there are no false positives, you can then deploy the changes to a broader group.

KB Article KB82925 shows all the available ATP rules. You can also refer to the ATP Rules Release Notes which are updated when new rules are created, or existing ones are modified.

Conclusion

We hope that this blog has helped highlight how ATP rules protect your environment against a variety of threats and, by combining this technology with others like AMSI, we reinforce protection.

This blog continues a series which help showcase our technology, so we also recommend reading the following:

McAfee Protects against suspicious email attachments

McAfee AMSI integration protects against malicious scripts

Using Expert Rules in ENS to prevent malicious exploits

What Is Mshta, How Can It Be Used and How to Protect Against It

 

All testing was performed with the JTI Content Version 1134 and MVISION Endpoint Version 20.1.0.114 (in High Protection)

The post How To Use McAfee ATP to Protect Against Emotet, LemonDuck and PowerMiner appeared first on McAfee Blog.

ENS 10.7 Rolls Back the Curtain on Ransomware

7 May 2020 at 04:02

Ransomware protection and incident response is a constant battle for IT, security engineers and analysts under normal circumstances, but with the number of people working from home during the COVID-19 pandemic that challenge reaches new heights. How do you ensure an equivalent level of adaptable malware protection on or off the corporate network? How do you enable remote services securely? How long will it take you to recover remote end user systems and data encrypted by ransomware?

As remote workers and IT engineers increasingly use Remote Desktop Protocol (RDP) to access internal resources, attackers are finding more weaknesses to exploit. Attackers are exploiting weak authentication or security controls and even resorting to buying RDP passwords in the underground markets. Exploiting these weaknesses can give an attacker admin access and an easy path to install ransomware or other types of malware, then find their way around the corporate network. To see some examples of how attackers are exploiting RDP weaknesses, check out additional blog posts from McAfee Advanced Threat Research (ATR)

In this blog, we will show how you can leverage Endpoint Security or ENS, McAfee’s Endpoint Protection Platform (EPP), led by some of the new capabilities in ENS 10.7 and MVISION Endpoint Detection and Response (EDR), to do just that.

ENS 10.7, with Threat Prevention, Firewall, Web Control and Adaptive Threat Protection modules backed up by Global Threat Intelligence (GTI) provides adaptable, defense in depth capability against the techniques used in targeted ransomware attacks. For more examples of these techniques, see McAfee ATR’s recent blog on LockBit. Pairing ENS 10.7 with MVISION EDR gives the SOC analysts a powerful toolset to quickly identify attempts to steal credentials and lateral move further into the network.

Finally, McAfee ePolicy Orchestrator (ePO) provides a central management console for endpoint security policy, event collection and reporting on your protected systems on or off the corporate network. Let’s explore some of the key defensive steps you can take to lower your risk against targeted ransomware.

Prevent Initial Access with Threat Prevention

The Endpoint Security Threat Prevention module contains several capabilities including signature scanning and exploit prevention through behavior blocking and reputation analysis, to prevent an attacker gaining access to the system. The first step is to ensure you have the minimum level of security in place. This includes following best practice for on-access and on-demand scanning policies, up to date DAT Files and Engine, and Exploit Prevention content, as well as Global Threat Intelligence access enabled. Targeted ransomware attacks may also leverage file-less exploit techniques which could bypass file-based signature scans and reputation checks. Exploit Prevention rules can be configured to either log or block PowerShell behavior.

However, PowerShell is a legitimate system administration tool and we recommend a period of observation and testing before setting any of these rules to block. For some best practice, you can review this guide as a starting point or check with support for the latest documents.

Restrict RDP as an Initial Attack Vector with Endpoint Security Firewall

If RDP is needed to access internal resources on a server or to troubleshoot a remote system, the best practice is to restrict access to the service using a firewall. This will prevent attackers from leveraging RDP as the initial access vector. ENS 10.7 contains a stateful firewall fully managed via McAfee ePolicy Orchestrator (ePO). You can create policies to restrict RDP access to a remote client to only authorized IP addresses, restrict outbound usage to prevent lateral movement by RDP or block access to that port altogether. Here is an example configuration to restrict inbound access to a remote system on RDP.

  1. Open your Firewall Rules policy and locate the default rule under Network Tools.

  1. If you are using a non-standard port for RDP adjust the local port for this rule appropriately.
  2. Modify the rule by adding authorized IP addresses as remote networks (these are the remote addresses authorized to connect to your endpoints).

  1. Save the changes and apply the policy to endpoints to restrict RDP access.

For additional security create an identical rule but set to block rather than allow, position it below the above rule, and remove the remote IP addresses (so that it applies to all RDP connections not matching the above rule).

  1. Set this rule as an intrusion so that it logs all denied events and forwards them to ePO.

Security analysts in the SOC can then monitor and report on unauthorized access attempts through ePO dashboards. The event logs are useful for early warning, trend analysis and for threat detection and response.

You can find more information on Endpoint Security firewall features here.

Prevent Access to Malicious Websites with Web Control

Attackers often leverage watering holes and spear phishing with links to malicious sites to gain initial access or further infiltrate the network. When a user is on the corporate network, they are often behind a Web Proxy like McAfee Web Gateway. However, many of your mobile clients are going direct to the internet and not through the corporate VPN. This creates more exposure to web-based threats. The Endpoint Security Web Control module monitors web searching and browsing activity on client computers and protects against threats on webpages and in file downloads.

You use McAfee ePO to deploy and manage Web Control on client systems. Settings control access to sites based on their safety rating, reputation from Global Threat Intelligence, the type of content they contain, and their URL or domain name. The configuration settings allow you to adjust sensitivity to be more or less restrictive based on your risk appetite.

If you are a McAfee Web Gateway or Web Gateway Cloud Service customer, you should use McAfee Client Proxy (MCP). MCP works with Web Control to route traffic to the right proxy and provide a defense in depth capability for web protection for users on or off the corporate network.

The above are just a few examples of using Endpoint Security Threat Prevention, Web Control and Firewall to restrict initial attack vectors. To learn more about Endpoint Security best practice to restrict initial entry vectors, visit here.

Let’s look at a few more important steps to protect systems against targeted ransomware.

Lockdown the Security Crown Jewels

If an attacker gets on the system through RDP stolen accounts or vulnerability, they may try to modify, delete or disable security software. In ePO, you should ensure that Self Protection is ON to prevent McAfee services and files on the endpoint or server system from being stopped or modified.

Ensure that ENS is configured to require a password for uninstallation.

 

Security analysts should be on high alert for any system that has Self Protection disabled. ePO contains a default query entitled Endpoint Security: Self Protection Compliance Status which can be used to populate a continuous monitoring dashboard or be packaged into a daily report.

Disrupt and Visualize Attacker Behavior with Adaptive Threat Protection (ATP)

ATP adds several more capabilities, such as machine-learning, threat intelligence, script-scanning and application behavior analysis, to disrupt targeted attack techniques including file-based or file-less attacks.

ATP identifies threats by observing suspicious behaviors and activities. When ATP determines that the context of an execution is malicious, it blocks the malicious activity, and if necessary, remediates (see Enhanced Remediation section below). How does this work? The Real Protect scanner inspects suspicious activities on client systems and uses machine-learning techniques to detect malicious patterns. The Real Protect scanner can scan a network-streamed script, determine if it is malicious, and if necessary, stop the script. Real Protect script scanning integrates with AMSI to protect against non-browser-based scripts, such as PowerShell, JavaScript, and VBScript.

For more information on how ATP remediates threats please review the product guide here.

One of the newest features of ENS 10.7 is the Story Graph. The Story Graph provides a visual representation of threat detections. Below is an example from a simulated file-less attack scenario where a Word document, delivered through spear-phishing, leverages a macro and PowerShell to provide command and control, then elevate privileges and perform lateral movement.

The visualization provides a timeline analysis and context around the event. It correctly captured the attack behavior including the communication to an external attacker IP address. With this visualization, an administrator or security analyst can quickly determine malicious behavior was stopped by ATP, preventing the follow-up activity intended by the attacker. The additional context, such as the originating process and a download IP address, can then be used for further investigations using other log sources, for example. It is important to note that in this example, if the Threat Prevention module as described above was set to block all PowerShell behavior, this attack would have been stopped earlier in the chain. Please read further to see what this attack scenario looks like in MVISION EDR.

For more information on how ATP protects against file-less attacks visit here.

Using a Word document and PowerShell is just one example of masquerading attacks in common files. For more examples of these techniques, see the ATR blog on LockBit ransomware.

ATP Brings Automatic File Recovery with Enhanced Remediation

If you have ever seen a ransom note, like the one from Wanna Decryptor below, you will know how big an issue it can be. It will cost you time, money and most likely lead to loss of data.

If this happens on a remote user system, it will lead to extended downtime, frustrated users and present significant challenges for recovery.

One of the new capabilities in ENS 10.7 is Enhanced Remediation. This feature monitors any process with an unknown reputation and backs up changes made by those processes. If the processes exhibit malicious behavior as determined by machine-learning analysis and reputation, enhanced remediation automatically rolls back those changes made to the system and documents to a previous state.

You can see how files impacted by ransomware can be restored through Enhanced Remediation in this video.

Enhanced Remediation requires that ATP is enabled and policies for Dynamic Application Containment are configured. Real Protect Dynamic scanning must also be enabled on the system. Real Protect Dynamic leverages machine learning in the cloud to identify suspicious behavior and is needed to determine a file reputation which is used to trigger an enhanced remediation action.

For information on how to configure ATP, please review the product guide here. For more best practices on tuning Dynamic Application Containment rules, please review the knowledge base article here.

Once policies are established, ensure that you enable “Enhanced Remediation” and “Monitor and remediate deleted and changed files”

If a file is convicted by Real Protect Dynamic and Enhanced Remediation is enabled with the settings above, then recovery happens automatically. The setting “Monitor and remediate deleted or changed files” must be enabled to ensure any files modified by the ransomware are restored to the previous state.

For more information on how Enhanced Remediation works, please review the product guide here.

Continuous Monitoring with ePO Protection Workspace

Now that you have protection controls in place with Threat Prevention and Adaptive Threat Protection, you can monitor using the Compliance Dashboard in ePO to ensure all managed clients stay up to date.

In addition, events triggered by ATP can be sent to ePO. SOC analysts should monitor these events and use the Story Graph as well for additional investigative capability. For more information on reporting and querying events in ePO, please review the product guide here.

Proactive Monitoring and Hunting with MVISION EDR

One of the first questions a threat hunter needs to answer when a new threat is discovered is “are we exposed?” For example, you may have a policy that already prohibits or restricts RDP but how do you know it is enforced on every endpoint? With MVISION EDR, you can perform a real time search across all managed systems to see what is happening right now. The screenshot below shows a Real-time Search to verify if RDP is enabled or disabled on a system. This provides a view into systems potentially at risk and can also be useful context as part of an investigation.

Real-time Search can also identify systems with active connections on RDP…

MVISION EDR also maintains a history of network connections inbound and outbound from the client. Performing an historical search for network traffic could identify systems that actively communicated on port 3389 to unauthorized addresses, potentially detecting attempts at exploitation.

For a security analyst, EDR providers several benefits to accelerate threat detection and response. For more information on those benefits please review the product guide here. In our simulated file-less attack scenario described above, the story graph revealed a PowerShell connection to an external IP address. Suppose an alert ePO administrator created a ticket for further investigation. A first step by the analyst might be a search for the network activity.

Real-time Search in EDR of that network activity looks like this…

An historical search for the same PowerShell activity in EDR now reveals the encoded commands used in the initial entry vector…

EDR also enables proactive monitoring by a security analyst. The Monitoring Dashboard helps the analyst in the SOC quickly triage suspicious behavior. In this case, the attack leveraged Word and PowerShell to gain access and raise privileges. The attack scenario triggered a number of high threats and provides a lot of context for the analyst to make a quick determination that an attack has been attempted, requiring further action…

Our research into targeted ransomware attacks reveals that if an attacker successfully exploits a client, their next actions involve privilege escalation and lateral movement (see our blog on LockBit). Again, you can use MVISION EDR to quickly detect these techniques.

The Alerting Dashboard in EDR will help you quickly identify attempts at privilege escalation and other attack techniques as defined by the MITRE ATT&CK framework.

Lateral movement is usually the next step and that can involve many different techniques. Again, the Alerting Dashboard identifies lateral movement techniques with details into the specific activity that triggered the alert.

Conclusion

Ransomware and RDP are a dangerous combination. Protecting your remote end users requires a good, secure baseline configuration of Endpoint Security with a Firewall and Self Protection enabled and access to adaptable capability such as Adaptive Threat Protection with Enhanced Remediation. The Enhanced Remediation feature is only available starting in version ENS 10.7, so if you are running older versions of ENS or even VSE (yikes), then it is time to upgrade.

However, stopping targeted ransomware from having an impact on the business requires more than prevention. Both ePO and EDR provide the capability for proactive detection, faster investigations and continuous hunting.

Finally, adaptability requires threat intelligence. McAfee Advanced Threat Researchers and Labs are actively monitoring the threat landscape and continuously updating McAfee Global Threat Intelligence systems. Make sure your Endpoint Security and other McAfee products are using GTI for the latest protection.

For more information on targeted ransomware attacks and techniques, see ATR Blog.

For more details about how to securing RDP access in general, you can refer to a previous McAfee blog.

The post ENS 10.7 Rolls Back the Curtain on Ransomware appeared first on McAfee Blog.

COVID-19 – Malware Makes Hay During a Pandemic

By: Sriram P
7 May 2020 at 04:01

Special thanks to Prajwala Rao, Oliver Devane, Shannon Cole, Ankit Goel and members of Malware Research for their contribution and monitoring of related threats

As COVID-19 continues to spread across the world, it is no surprise that malware authors are exploiting the pandemic. McAfee recently released blogs around Covid-19 related threats – Staying safe while working remotely, COVID-19 Threat Update Now Includes Blood for Sale and Transitioning to a Mass Remote Workforce. The first discusses how attackers would like to leverage this pandemic as an opportunity to attack organizations, the second gives a preview of attackers playing on the fears of the general public grappling to get a hold of a cure, help manage this illness and stay safe while the third gives some direction to organizations on how to verify their security controls. In this blog we continue to discuss COVID-19 themed attacks and how to stay vigilant.

The weeks of quarantine have forced individuals and organizations to quickly adapt to a work from home model. A lot more time is spent indoors and online and there continues to be anxiety around when normalcy will be restored. For now, we continue to deal with a barrage of news articles around the pandemic, managing supply and demand of household goods in stores and online, and a shortage of medical supplies such as preventative masks, gloves and sanitizer. These are trying times for us and a feast for fear mongering malware criminals.

Over the last few months of 2020, McAfee researchers have been hard at work during this time to keep our customers safe by more directed monitoring and adaptation of our detection stack to better manage the COVID-19 threat landscape. This is not intended to be an exhaustive report due to the scope of a continually evolving landscape for COVID-19; therefore, we cover a subset of threats directed towards malware, spam and malicious/scam URL campaigns.

This blog serves to remind customers to utilize the various levers present in our endpoint product and our expanded portfolio such as McAfee’s Unified Cloud Edge. Please read our recommendation section and view our IOC section (partial IOC list based on this article), expert rules section (covers few tactics based on this article). McAfee utilizes several internal and external sourcing techniques for malware harvesting including collaboration with other industry partners as part of the Cyber Threat Alliance.

Table of contents:

Timeline

The timeline below shows a subset of prevalent malware families observed in our spam traps with references to COVID-19/Coronavirus. The malware shown in this timeline have been chosen due to their capacity for damage (such as ransomware) or their ability to propagate (Emotet for spam, or other worm like activities).

A weekly distribution of all known COVID related IOCs per week is shown below.

 

Malware

This section covers a subset of the Malware families included in the timeline above and shows the various IOCs that referenced the virus. For a more comprehensive list of IOCs please refer to the IOC section.

Ursnif

The first threat we observed taking advantage of the pandemic was Ursnif. Ursnif is a banking Trojan aimed to steal banking credentials and has been evolving to become more powerful. Ursnif collects system activities of the victims, record keystrokes, as well as keep track of network traffic and browser activity.

We have observed Ursnif using the COVID-19 filename to entice users since January 2020.

 

On executing the VBS file it drops a dll in C:\Programdata\FxrPLxT.dll and executes the .dll with rundll32.exe. The dll is injected into iexplorer.exe and communicates with its C&C server using http get requests.

IOCs

Type IOC Comment
Sha256 e82d49c11057f5c222a440f05daf9a53e860455dc01b141e072de525c2c74fb3 Filename: Coronavirus_disease_COVID-19__194778526200471.vbs
Sha256 8bcdf1fbc8cee1058ccb5510df49b268dbfce541cfc4c83e135b41e7dd150e8d Ursnif dll

 

MITRE ATT&CK™ MATRIX:

Technique ID Tactic Technique details
T1059 Execution Command-Line Interface
T1129 Execution Execution through Module Load
T1085 Defense Evasion, Execution Rundll32
T1060 Persistence Registry Run Keys / Startup Folder
T1055 Defense Evasion, Privilege Escalation Process Injection

 

Fareit

Fareit is an information stealer that steals data from web browsers, FTP programs, email clients and over a hundred different software tools installed on the infected machine. We have observed several Fareit phishing emails with the COVID/Coronavirus name. A few of them are shown below.

Fareit Spam 1:

IOCs

Type IOC Comment
Sha256 da1443a25f433e23a43d35d50328a4f935d3cce840f1e3cca99b6bd6d49ed6a7 Dropped Binary
Sha256 9f4bb022b49bd6ba0766e9408139648d2ddfe2f0dd5ca14644e5bdb2982b5e40 Email

 

MITRE ATT&CK™ MATRIX:

Technique ID Technique Technique details
T1193 Initial Access Spear phishing Attachment
T1106 Execution Execution through API
T1130 Defense Evasion Install Root Certificate
T1081 Credential Access Credentials in Files
T101 Discovery Query Registry

 

Fareit Spam 2:

IOCs

Type IOC Comment
Sha256  2faf0ef9901b80a05ed77fc20b55e89dc0e1a23ae86dc19966881a00704e5846 Attachment
Sha256 38a511b9224705bfea131c1f77b3bb233478e2a1d9bd3bf99a7933dbe11dbe3c Email

 

MITRE ATT&CK™ MATRIX:

Technique ID Technique Technique details
T1193 Initial Access Spear phishing Attachment
T1106 Execution Execution through API
T1130 Defense Evasion Install Root Certificate
T1081 Credential Access Credentials in Files
T1012 Discovery Query Registry
T1071 C & C Standard Application Layer Protocol

 

Fareit Spam 3:

IOCs

Type IOC Comment
Sha256 11a834cda4a55c8adb663fbcdd4b1f1018715dd737d3089a731b9840b77e5e76 Dropped Binary
Sha256 45c6440bdd7b49023bb42f9661caae3b12b579dfd5ae9e64421923ef452a0faf Email
Sha256 095bfab52666648ff4d2636a3718a28eab4d99a6c178a8c7912197221dd1d195 Email

 

MITRE ATT&CK™ MATRIX:

Technique ID Technique Technique details
T1193 Initial Access Spear phishing Attachment
T1106, T1204 Execution Execution through API, User Execution
T1060 Persistence Registry Run Keys / Startup Folder
T1130 Defense Evasion Install Root Certificate
T1081 Credential Access Credentials in Files
T1012 Discovery Query Registry
T1114 Collection Email Collection

 

Fareit Spam 4:

IOCs

Type IOC Comment
Sha256 f8e041bed93783bbd5966bfba6273fe7183464035ea54fe1d59ff85a679b3e3e Dropped Binary
Sha256 9e17f5e70c30ead347b68841fa137015d713269add98f0257fb30cc6afdea4fe Attachment
Sha256 ada05f3f0a00dd2acac91e24eb46a1e719fb08838145d9ae7209b5b7bba52c67 Email

 

MITRE ATT&CK™ MATRIX:

Technique ID Technique Technique details
T1193 Initial Access Spear phishing Attachment
T1204 Execution User Execution
T1071 Command and Control Standard Application layer Protocol

 

COVID-19 Ransomware

It was no surprise that a new Ransomware family appeared on the scene. Once executed, Ransomware-GVZ will delete shadow copies with vssadmin and then proceed to encrypt all non-pe file types.  Once a whole folder has been encrypted the ransom note file below is created.

Ransomware-GVZ will also create a lock screen component so that when the machine is rebooted the following message is displayed.

 

IOCs

Type IOC Type
Sha256 3299f07bc0711b3587fe8a1c6bf3ee6bcbc14cb775f64b28a61d72ebcb8968d3 Binary

 

MITRE ATT&CK™ MATRIX:

Technique ID Tactic Technique details
T1486 Impact Data Encrypted for Impact
T1083 Discovery File and Directory Discovery
T1490 Impact Inhibit System Recovery

 

Emotet

Emotet is another prevalent threat distributed via phishing emails. We observed the following email being distributed which translated to English is:

Subject: 

Break !!! COVID-19 solution announced by WHO at the end How a total control method is discovered

Email Body:  

As published in the newsletter of the World Health Organization 3/17/2020 7:40:21 a.m. A new collaborative study identified and studied antibodies to the COVID-19 virus which could be used to design effective universal therapies against many different species of COVID-19 viruses. The results have recently been published in Nature Microbiology.

These are based on natural activities and how heat helped inhibit the virus from growing.

The COVID-19 virus causes a serious disease with high mortality badgers in humans. Several strategies have been developed to treat COVID-19 virus infection, including ZMapp, which has proven effective in non-human primates and has been used below compassionate treatment protocols in humans …

 

Please download the full text in the attached document …

Also share with all contacts to ensure quick epidermal control.

The email contains a zipped Emotet executable which once executed will use the process hollowing technique to inject into regasm.exe. It will then contact its C&C server and being to send spam email out.

IOCs

Type IOC Comment
Sha256 ca70837758e2d70a91fae20396dfd80f93597d4e606758a02642ac784324eee6 Attachment
Sha256 702feb680c17b00111c037191f51b9dad1b55db006d9337e883ca48a839e8775 Email

 

MITRE ATT&CK™ MATRIX:

Technique ID Tactic Technique details
T1121 Defense Evasion, Execution Regsvcs/Regasm
T1093 Defense Evasion Process Hollowing

Azorult

Azorult is a malware that steals data from victim’s machine which includes username, passwords, cryptocurrencies, browsing history and cookies. It also can download additional malware onto the victim’s machine. What sets Azorult apart from the other Malware described in this report, is that the creators of Azorult created a fake Coronavirus infection map website (corona-virus-map[.]com). The fake website appears as below:

IOCs

Type IOC Comment
Sha256 c40a712cf1eec59efac42daada5d79c7c3a1e8ed5fbb9315bfb26b58c79bb7a2 Jar file from domain
URL H**p://corona-virus-map.net/map.jar
Sha256 63fcf6b19ac3a6a232075f65b4b58d69cfd4e7f396f573d4da46aaf210f82564 Dropped Binary

 

MITRE ATT&CK™ MATRIX:

Technique ID Technique Technique details
T1059 Execution Command-Line Interface
T1012 Discovery Query Registry

 

NetWalker

Another Ransomware which has leveraged COVID-19 is Netwalker. The Ransomware used the filename “CORONAVIRUS_COVID-19.vbs” to trick users into executing it. The VBS file contained the embedded Ransomware payload.

On execution of vbscript, the Ransomware is dropped in “C:\Users\<UserName>\AppData\Local\Temp\qeSw.exe” and executes it.

It Deletes the shadow copies from the machine with vssadmin.exe to make file recovery more difficult.

Below shows the Obfuscated vbscript

The ransomware iterates through the folders of the infected machine and encrypts the files. Once encrypted the file extension is changed to <filename>.1fd385. A ransom note is also dropped in each folder where files were encrypted. This note is shown below.

IOCs

Type IOC Comment
Sha256 9f9027b5db5c408ee43ef2a7c7dd1aecbdb244ef6b16d9aafb599e8c40368967 CORONAVIRUS_COVID-19.vbs
Sha256 8639825230d5504fd8126ed55b2d7aeb72944ffe17e762801aab8d4f8f880160 Dropped Binary

 

MITRE ATT&CK™ MATRIX:

Technique ID Tactic Technique details
T1204 Execution User Execution
T1064 Execution Scripting
T1106 Execution Execution through API
T1490 Impact Inhibit System Recovery
T1486 Impact Data Encrypted for Impact

 

 

Nanocore RAT

NanoCore is a Remote Access Trojan (RAT) and its highly customizable plugins allows attackers to tailor its functionality to their needs. This RAT is also found to be using COVID-19 to distribute itself by using email subjects such as “Covid-19 Urgent Precaution Measures”.

IOCs

Type IOC Comment
Sha256 ca93f60e6d39a91381b26c1dd4d81b7e352aa3712a965a15f0d5eddb565a4730 Dropped Binary
Sha256 89b2324756b04df27036c59d7aaaeef384c5bfc98ec7141ce01a1309129cdf9f Iso Attachment
Sha256 4b523168b86eafe41acf65834c1287677e15fd04f77fea3d0b662183ecee8fd0 Email

 

MITRE ATT&CK™ MATRIX:

Technique ID Technique Technique details
T1193 Initial Access Spear phishing Attachment
T1053 Execution Scheduled Task
T1060 Persistence Registry Run Keys / Startup Folder
T1143 Defense Evasion Hidden Window
T1036 Defense Evasion Masquerading
T1497 Defense Evasion Virtualization/Sandbox Evasion
T1012 Discovery Query Registry
T1124 Discovery System Time Discovery
T1065 Command and Control Uncommonly Used Port

 

 

Hancitor

Hancitor trojan has also uses COVID–19 themes to spread itself by posing as an email from insurance company. The email contains a link to download a fake invoice which downloads a VBS file.

On executing the VBS, the Hancitor dll temp_adobe_123452643.txt is created in the %AppData/Local/Temp folder. The DLL is executed using the Regsvr32.exe and then begins to communicate with its C&C.

 

IOCs

Type IOC Comment
Sha256 2f87dd075fc12c2b6b15a1eb5ca209ba056bb6aa2feaf3518163192a17a7a3 Downloaded Binary
Sha256 0caef2718bc7130314b7f08559beba53ccf00e5ee5aba49523fb83e1d6a2a347 Downloaded Binary
Sha256 375d196227d62a95f82cf9c20657449ebea1b512d4cb19cdfe9eb8f102dd9fa Downloaded Binary
Sha256 0b8800734669aa7dbc6e67f93e268d827b5e67d4f30e33734169ddc93a026 Downloaded Binary
Sha256 9c40426f157a4b684047a428428f882618d07dc5154cf1bf89da5875a00d69c Email

 

MITRE ATT&CK™ MATRIX:

Technique ID Technique Technique details
T1192 Initial Access Spear phishing Link
T1064 Execution Scripting
T1117 Execution Regsvr32
T1071 Command and Contro Standard Application layer

Protocol

 

Heat Map

This detection heat map shows a snapshot of the various countries where McAfee has observed a detection for known IOC’s since mid-January. We have observed detections in almost all the countries which have been impacted by the COVID-19 pandemic.

Spam

There have been thousands of COVID-19-themed spam emails sent daily. They range from medical supply scams to extortion. Below are a few examples of the ones we have observed.

 

URL

We have observed the number of Malicious URLs with references to COVID-19 and Coronavirus spike in the last few weeks. The numbers increased from 1,600 a few weeks ago to over 39,000 in week 13. This highlights the importance of being vigilant when clicking on links and accessing websites as the number of malicious sites is increasing exponentially.

 

Here are examples of malicious websites we have. False advertising is a common practice during such pandemics. At the time of this writing, there aren’t any quick testing kits available. Also testing is initiated by health care providers and therefore it is important to educate yourself and others around you to not buy into scams.

The following is an example of a fake website which offers Coronavirus testing services.

Face masks have been in high demand and in many places have run out. Additionally, there has been a shortage of masks even with the health care community. At times of panic and shortage, it is common for spammers to send out links to fake sites claiming to have medical supplies equipment. Here is a screenshot of fake online shop selling face masks.

GTI provides categorization and classification of links serving malware, phishing, scamming etc. McAfee products leverage GTI for URL protection. Also, McAfee’s Unified Cloud Edge provides secure access and expands your capabilities for URL protection.

Read about an example of one McAfee researcher is giving back by 3D printing masks and shields.

IOCs

Below is a partial list of IOCs we have observed in the field which have taken advantage of the Covid-19 outbreak. The IOCs in this section are a subset of those detected by McAfee’s solutions. We have broader coverage provided by our GTI Cloud, gateway, ATP and other products in our portfolio.

Type Value
SHA256 2ec4d4c384fe93bbe24f9a6e2451ba7f9c179ff8d18494c35ed1e92fe129e7fa
SHA256 7e52f7a7645ea5495196d482f7630e5b3cd277576d0faf1447d130224f937b05
SHA256 69724a9bd8033bd16647bc9aea41d5fe9fb7f7a83c5d6fbfb439d21b7b9f53f6
SHA256 f92fecc6e4656652d66d1e63f29de8bfc09ea6537cf2c4dd01579dc909ba0113
SHA256 a5ab358d5ab14b81df2d37aedf52716b5020ab45da472dedc8b8330d129d70bf
SHA256 8028f988c145b98ddd4663d3b5ec00435327026a8533924f7b8320c32737acf4
SHA256 aab93bf5bb0e89a96f93a5340808a7fa2cebf4756bd45d4ff5d1e6c8bdccf75d
SHA256 2e93fe77fafd705e6ca2f61f24e24a224af2490e0a3640ed53a17ea4bf993ec8
SHA256 f850f746f1a5f52d3de1cbbc510b578899fc8f9db17df7b30e1f9967beb0cf71
SHA256 dd78b0ecc659c4a8baf4ea81e676b1175f609f8a7bba7b2d09b69d1843c182cb
SHA256 e352c07b12ef694b97a4a8dbef754fc38e9a528d581b9c37eabe43f384a8a519
SHA256 e82d49c11057f5c222a440f05daf9a53e860455dc01b141e072de525c2c74fb3
SHA256 8bcdf1fbc8cee1058ccb5510df49b268dbfce541cfc4c83e135b41e7dd150e8d
SHA256 95489af84596a21b6fcca078ed10746a32e974a84d0daed28cc56e77c38cc5a8
SHA256 002c9e0578a8b76f626e59b755a8aac18b5d048f1cc76e2c12f68bc3dd18b124
SHA256 da1443a25f433e23a43d35d50328a4f935d3cce840f1e3cca99b6bd6d49ed6a7
SHA256 08c1aca51ae6917ed138ec70cc7768b935d13fbd743e85191877006626fdc530
SHA256 a9864b548d71c95333efd81d9fb000347bc715c7430e24f37f5bbbde4f2adf39
SHA256 8deba9fb53096d6ea5e2090b662244293829096eee03d06108deb15e496a807e
SHA256 c3477ca9a51e9eb1a93188fe2bd412830163f44b0954573d225736c530dd5fd2
SHA256 3e6166a6961bc7c23d316ea9bca87d8287a4044865c3e73064054e805ef5ca1a
SHA256 11a834cda4a55c8adb663fbcdd4b1f1018715dd737d3089a731b9840b77e5e76
SHA256 bc03c23a46a545addd1831e133b74bd2e62eb920041f18a23ec9719ea052e642
SHA256 8075381d210f7e79ee387927b7d6d690521c01ba6d835d07c4e8f023b3c164ce
SHA256 75d7d989deea561443c1c204ad22537d0c131f57820594ab5f07baba16dbc58b
SHA256 0cc54663439a55191b77e0735b7460a7435dc01542e910d75eae20ce7bb513e5
SHA256 c40a712cf1eec59efac42daada5d79c7c3a1e8ed5fbb9315bfb26b58c79bb7a2
SHA256 63fcf6b19ac3a6a232075f65b4b58d69cfd4e7f396f573d4da46aaf210f82564
SHA256 ca93f60e6d39a91381b26c1dd4d81b7e352aa3712a965a15f0d5eddb565a4730
SHA256 9f9027b5db5c408ee43ef2a7c7dd1aecbdb244ef6b16d9aafb599e8c40368967
SHA256 8639825230d5504fd8126ed55b2d7aeb72944ffe17e762801aab8d4f8f880160
SHA256 0caef2718bc7130314b7f08559beba53ccf00e5ee5aba49523fb83e1d6a2a347
SHA256 375d196227d62a95f82cf9c20657449ebea1b512d4cb19cdfe9eb8f102dd9fae
SHA256 0b8800734669aa7dbc6e67f93e268d827b5e67d4f30e33734169ddc93a026d2e
SHA256 12f87dd075fc12c2b6b15a1eb5ca209ba056bb6aa2feaf3518163192a17a7a3b
SHA256 f8e041bed93783bbd5966bfba6273fe7183464035ea54fe1d59ff85a679b3e3e
SHA256 ca93f60e6d39a91381b26c1dd4d81b7e352aa3712a965a15f0d5eddb565a4730
SHA256 da1443a25f433e23a43d35d50328a4f935d3cce840f1e3cca99b6bd6d49ed6a7
SHA256 3386dc7dc67edd5e84244376b6067e3767e914a1cc1fc7fd790a6aa68750a824
SHA256 3fc33b537fb38e1f586ddb3ebbbe152458dcde336c2f26da81d756e290b5ef00
SHA256 7cbcad4d6e9ad8438e5febd3830bff9aef4729b98d23935ad7f9e6d290272732
SHA256 0a84308348fee6bbfe64a9ef23bb9c32cb319bcdf5cf78ddfda4a83dadea4b8e
SHA256 ba4297978b6a6b5fe2b66c32ead47bbd1f2e2f549beed5cd727eb9ae3fed6b6a
SHA256 c9d3c250ab6d8535b7a4114a1e9545f0b9bc24e4e277640c59b7555f38727885
SHA256 37354a04f6d423809602e198e590469173cc8e930cc7fdd4da2c2072977251e9
SHA256 3a7a8518b41dd6c05289a08974c95a0038be4e5d1b0588edfd0589fcf22b0c8f
SHA256 ea3a0a223474592635d1fb7a0731dd28a96381ad2562e3e064f70e2d4830c39d
SHA256 140da6b610a45f84c6438207ab11942d79eb37831551810f87baae80cfff4593
SHA256 2c9c1e04d806ad8890dd6bf4477efb4ea6c78b8185a9996876bcaea568a04e70
SHA256 8a724fc60bde738694779751d6c63a7ed1caa03518b8f26b9acb36d5c1b29930
SHA256 d765980228492758a11e534e45924311aef681cb5859f701cd457b6b871c2d06
SHA256 d8183919d675978d58cd1f134768f88adeea9ce53b167c917e54fff855c6d9f9
SHA256 ac416780fa4aa340fff2787e630351c5813faceb823424817eb10e82254b785d
SHA256 3cd099efe4cb426fdc6276380c224b5478d0841c5c44d2c0a088d039d529d258
SHA256 c135f36d3346699e6d2bf9f5f5f638fd9475c0b12144a15a0652b8f1ebb25c12
SHA256 49cfa1b3cbe2bf97079c0dd0a9f604e3f2e7d9fbb6d41128a9889e068aa884f6
SHA256 5e20a0ab563950eab76c023101b1dd374becac2a5149a74320b23b59a7f16256
SHA256 7a9f249978c959e1f11f2992a8ce4a70ba333c8dbdc2638c780bbbe62de4808e
SHA256 c6dc408d60c2354a13e835bf826300a6d5258b72b8826e8c46d946cbc1f0b455
SHA256 b04584ee8b3ba565541cb0f4d8787ed6e8942b6bdec5b1acdc03488b93aeb3cb
SHA256 b283e4f841e328f0cc12ebdf76aafb819ebadba7df863681994b69697731cf96
SHA256 adde95e8813ca27d88923bd091ca2166553a7b904173ef7a2c04bb3ddf8b14a9
SHA256 bf178911f2c063c9592020652dc22076d02ca87d14a7ed7862074d334470ae32
SHA256 3981d933de93f55641fdf8cfe980e40a0bf52ce8b022735e8ebc4f08cbb19104
SHA256 aa6ceb17ced471e1695c99c0718bc24c710311f0daa256cb0783d82218d772c9
SHA256 f7209d1099c75acccbef29450271d821fd78ad52176f07aa8a93a9e61e9eaa7f
SHA256 eab14b1bfa737644f14f7bb7ace007d418230285364e168e35bd718a6517b316
SHA256 b34f4ec4ae8d66b030f547efe3acc2a71c9ab564f78aac68719ec91dab613bb3
SHA256 006dc4ebf2c47becdc58491162728990147717a0d9dd76fefa9b7eb83937c60b
SHA256 e17dca7c2c05139fc81302e76e0e9aaa29368b60cb147208cbcb5c8df113f6f6
SHA256 2e47f37bef4dea338e366ce30fe54888e5aaa2d47a5c0db4a3c3e9e5c25f8ace
SHA256 21182b7834a7e13033be7b370a68b3d3639f4cae12fe80e2a908404cbd4cd324
SHA256 46f81af256c630969f55554ea832037bc64df4374ec0f06ac83a1c4b89869314
SHA256 89a0147dec8d6838f14815b577ae41dbcf54953c66e7f5f999ab91fea6ec08fa
SHA256 2f3ee4688a31c8d249b8426f46e392d9c55b85bfad9fb31fb362eb32d38bd9b3
SHA256 f2a2bea86ce1a4803345b4aa46824c25d383a0b40b10bb69e528c72305552a2a
SHA256 698eb726345c71eca7b4a531bfa76ab6e86ef100f943a727fb5866a84ec79289
SHA256 92af9c8c539ff9f99f79cce8453b1c483d117c095e2e0ffe384d96e35f72dc8b
SHA256 7cf8f24d7e8b1e2f63bfa7a18cd420a03fff44126e80aed8cb90fba3c4e986ac
SHA256 1e4b01e3e146ff01a3782b01680a5165432af556331d599ec6ad35b4983b216f
SHA256 cba1c3070f76e1a2705afee16bd987b6a8ffa45900cab8cf3b307f60a7b89ac9
SHA256 e32cca6446f2ddd8430400b16fc171ab3163cf8222669d7d9144e9c85904d5f5
SHA256 8c0a8d6876a6c7fe44962883561d9f48615ee67f4544872ec98f47edcf516509
SHA256 a080d763c60efd4ef2781ad3090c997d1092ac726707366d92d647f26ee2965f
SHA256 9d58ca5383fef5dc837ca9d4251d247bed4ead4a6b90a9aae30568be80e20543
SHA256 345d8b4c0479d97440926471c2a8bed43162a3d75be12422c1c410f5ec90acd9
SHA256 39c17475bdb019010453085830e7f8aa1ef41ca182982491306fcf75166b8e08
SHA256 bdcef0f16c70086414ff95b69fdbbe7eb0c9814308d3d60143b6c04dfc077257
SHA256 7a97fc7bdd0ad4ef4453c2e52dd8f44dee9b4e91ff3b5518e311ef1ebac3b667
SHA256 2437ef90b60cf3d6bd0c3eebf3f41ed1e403bc31b024b52b0f41ec648d80a583
SHA256 a537c75de9a95be0c071fd6437cbaf3696752f02c3cd5afa1c9cc47c4c755f75
SHA256 9367f3ea7460ae40ca69d41398327f97136a93656ef5fad1285a0b82f81522a4
SHA256 78cf7ea3c1da98941e164f4ac3f75b57e9bce11467bc5a6c6877846f1adcf150
SHA256 e55efa92d87484cf6b251f2302a0c0c7650acd7ea658bf9997bf761b64fe472a
SHA256 51f0e9b151bde97ebeb813d6eed8a11f02551a6530049f53dc29fc1a20b6699d
SHA256 e382ee1ce9d99f4e8e18833bac121c14ee2e5dc29a8b5382ca5b4eda9db7f1aa
SHA256 e250d977e47e7809086dd35a2767f9ef557591dd00e9ce96ef4071e4f0d8c670
SHA256 50a3bea4b9686bcf5cac144d4fc18aa178f66c8368205f9065cd1d9a2c41f026
SHA256 722a60dfd59a595daa487f2fb759ef6f9ccaabcdf20605d5ae9450cba4a9b9b2
SHA256 1c3532d143212078e204d0f81a782deacd58e8f0e7253472e0509491fd1e5201
SHA256 980de93ad93ecaabc048c9fcc9d62e43eeb32f216c4177963cf1bd94ad53074b
SHA256 a286e3be694b9525530ec6a65b71a8a91e04042c3471e8a9e440f503fe8ce995
SHA256 dbcef5c217a027b8e29b1b750c42a066650820a129543f19364bcb64ac83bc07
SHA256 80f8877406e899c6274331aa991b8d1f4f087e3233c36d39fbaebb729c294899
SHA256 32753598f94412fe3dc382dc12dcf2edf7881d9f07814c82aeec36481b9362b5
SHA256 0fdc97da1c297e6fef93910008fc5c47cbdcd3e2987bc163467b34f56de112ff
SHA256 501cc107e410b245d1b95b64ae0afdae758375b4b3724acfda44041bad963232
SHA256 31cb82cd750af6af9ecf369fd26d47dc913f6b56be6ea12b10fe6dd90ef1b5df
SHA256 da87521ecc146a92a7460a81ebb5ca286450f94c8c9af2a4b3c6c8a180d421c5
SHA256 2bcd35bfb7e4dbdbbf64fce5011199947794425093be7bc74829bfeadb89f0a3
SHA256 90c3d8d13ea151bce21a1f4b842d0ed4eaff09842b23311b2326cf63957fc2b2
SHA256 257afe9f4d7b282b1c0b2f3ebb7e1e80e96c8e0214f1b80ea2b7b636a4e7747d
SHA256 587840d28f2585dd5207731d7fda86a0966c82fa592a26f9148b2de45526db55
SHA256 80ee20c604d5d4b51a30dc21da271651f3c085c40281e3ff3e2ee0175d2ca98d
SHA256 11b4519b76957b0758381f8e19c5e15d8744f7974716642aeb586c615dde38fa
SHA256 6c34cca35d98e464c2f74abd9be670c7f8f707f37cd3f0fd4746c49f8fcf6b07
SHA256 0a8aa3f413a8989bb89599dfc2404f7d34dfbb2e3ce26e900d228e9e8c8908b8
SHA256 c57fa2a5d1a65a687f309f23ca3cfc6721d382b06cf894ee5cd01931bbc17a46
SHA256 9f27a826b4b873c9ea23e023f54d5291a50004d67dd5fe64d1f8c8e8b51b74e3
SHA256 2037c7cc809ed3eddd1338d2bec6266cdb449dbf8ff3510fd360a08d229d4f40
SHA256 8f91d27d3a59c08ab4c453b2679f4620696ba67c56280a4c3757368acb20aad3
SHA256 e8221acccdb8381b5da25a1f61f49dda86b861b52fafe54629396ed1e3346282
SHA256 dc66811ce189240c510733be9e1a2175079dddb80ebf02faaa044fce1f7134d0
SHA256 5b7db5046ba22a6242d5ff6e8f538ad43bba53810117d5eb8f023215aad26e6b
SHA256 f6879431b901df789082452c1c4ffa29e857d247886e421df6dda5fb3d81ca5e
SHA256 4a272dd4a5c6261e983d667dd676875054dd4a4ea11620f16c553fcfd2c44861
SHA256 cc2507ddd53a6f00265f3be51d7217def786914bd1d700ec3c74a2a7107b3476
SHA256 9e4cb963e509fbde6de003a81a3e19cfc703be1c41d20f4b094a0fa89d6ad02c
SHA256 b14d70827d5d668aeb31e94be512fea9fb38ead8ec12cdf7617616801c76b6e9
SHA256 b49c9eba58537f8d856daded80bc9493a83c508d73423b98686d4e8b232d61c3
SHA256 4c9e35f3d5f555dda5f4373cf23fbb289c6067c70841be7022ba6da62e49cccb
SHA256 acec0bb9d9bd199d3e6a77b763cebee8f67275996d3c55af8c617fef76f2e87f
SHA256 7cbcad4d6e9ad8438e5febd3830bff9aef4729b98d23935ad7f9e6d290272732
SHA256 c9c0180eba2a712f1aba1303b90cbf12c1117451ce13b68715931abc437b10cd
SHA256 c322d10ef3aa532d4625f1c2589eae0f723208db37a7c7e81e4f07e36c3a537e
SHA256 3c756d761e89a0ea1216e2b7e57250ac76a80d5fe4f072e3b4b372e609ece74e
SHA256 2a42f500d019a64970e1c63d48eefa27727f80fe0a5b13625e0e72a6ec98b968
SHA256 679a8519587909f655bacea438168cbb4c03434aede9913d9a3a637c55a0eae7
SHA256 e9766b6129d9e1d59b92c4313d704e8cdc1a9b38905021efcac334cdd451e617
SHA256 80392bebe21245128e3353eec7f499bdc5550e67501eceebf21985644d146768
SHA256 215c72df44fe8e564d24f4d9930c27409e7f76e2045c67940cdcecdbdbd3b04f
SHA256 9e12094c15f59d68ad17e5ed42ebb85e5b41f4258823b7b5c7472bdff21e6cee
SHA256 1c98a36229b878bae15985c1ae0ff96e42f36fa06359323f205e18431d780a3b
SHA256 e9621840e1bfaf16eaee37e2d1e9d1f0032158a09e638eaebff6d8626d47c95a
SHA256 c51658ed15a09e9d8759c9fbf24665d6f0101a19a2a147e06d58571d05266d0a
SHA256 5187c9a84f5e69ba4b08538c3f5e7432e7b45ac84dec456ea07325ff5e94319a
SHA256 ddb24e0a38ba9194fe299e351e54facb2cca9e6011db2f5242210284df91f900
SHA256 69724a9bd8033bd16647bc9aea41d5fe9fb7f7a83c5d6fbfb439d21b7b9f53f6
SHA256 d7f15f750cceeb9e28e412f278949f183f98aeb65fe99731b2340c8f1c008465
SHA256 238fa49ed966cb746bffee3e7ca95b4a9db3bb0f897b8fd8ae560f9080749a82
SHA256 69724a9bd8033bd16647bc9aea41d5fe9fb7f7a83c5d6fbfb439d21b7b9f53f6
SHA256 f92fecc6e4656652d66d1e63f29de8bfc09ea6537cf2c4dd01579dc909ba0113
SHA256 5b12f8d817b5f98eb51ef675d5f31d3d1e34bf06befba424f08a5b28ce98d45a
SHA256 3b701eac4e3a73aec109120c97102c17edf88a20d1883dd5eef6db60d52b8d92
SHA256 b49c9eba58537f8d856daded80bc9493a83c508d73423b98686d4e8b232d61c3
SHA256 acec0bb9d9bd199d3e6a77b763cebee8f67275996d3c55af8c617fef76f2e87f
SHA256 4c9e35f3d5f555dda5f4373cf23fbb289c6067c70841be7022ba6da62e49cccb
URL https[:]//onedrive[.]live[.]com/download?cid=265DAF943BE0D06F&resid=265DAF943BE0D06F%21171&authkey=AMI1YV6jNxclaec
URL http[:]//popeorigin[.]pw
URL http[:]//dewakartu[.]info/wp-includes/BRVMFYvIR/
URL http[:]//drhuzaifa[.]com/wp-includes/2i48k7-evv28gw-205510/
URL http[:]//dewarejeki[.]info/wp-includes/up58jauc-pum2w-630352/
URL http[:]//rasmus-plius[.]tomasjs[.]com/wp-admin/KfesPCcG/
URL http[:]//easytogets[.]com/xfxvqq/UxbKAbm/
URL https[:]//cloud-security[.]ggpht[.]ml
URL http[:]//secure[.]zenithglobalplc[.]com/assets/plugins/bootstrap-wizard/system_x64[.]exe
URL http[:]//motivation[.]neighboring[.]site/01/index[.]php
URL https[:]//onedrive[.]live[.]com/download?cid=265DAF943BE0D06F&resid=

265DAF943BE0D06F%21171&authkey=AMI1YV6jNxclaec

URL http[:]//tailuong[.]com[.]vn/[.]xxx/playbook/onelove/fre[.]php
URL https[:]//www[.]onetimeroma[.]com/lost/rockstar[.]php
URL https[:]//www[.]chapeauartgallery[.]com/SUPPORTS/locals[.]php
URL http[:]//www[.]discusshoops[.]com/DISQUS[.]php
URL https[:]//chomyflozy[.]duckdns[.]org
URL http[:]//www[.]slacktracks[.]info/e12/?LJfxZ=hO3hBkxu1F/QQoVtLv3IhDwCcknmtRcJonnhtJ3R0BM0GC3rHSS1kgq0DEskVYHjDJX+/Q==&Vp8h=cz7tTz9p-90h4gt
URL http[:]//www[.]webfeatusa[.]net/e12/?LJfxZ=1CbYOqydIT70m9XPNsNZ3X3NgDEVQnw/rRrz+k+vF8uL+qJ4J3WKysbsjxdZCzgGrC1++w==&Vp8h=cz7tTz9p90h4gt&sql=1
URL http[:]//www[.]makeupprimerspray[.]com/e12/?LJfxZ=NSQopDdawCOOQSyQXUSgSx+w/7t91r6e8z0AUnmVGKAxI+P615MDhQgbvUIoIJuh35rtRQ==&Vp8h=cz7tTz9p90h4gt&sql=1
URL http[:]//mercadosonntag[.]com[.]br/sK2vbV3
URL https[:]//corona-virus-map[.]net/map[.]jar
URL http[:]//corona-virus-map[.]com
URL http[:]//arinnnnnnnn[.]ddns[.]net
URL http[:]//tailuong[.]com[.]vn/[.]xxx/playbook/onelove/fre[.]php
URL http[:]//bralibuda[.]com/4/forum.php
URL http[:]//greferezud[.]com/4/forum[.]php
URL http[:]//deraelous[.]com/4/forum[.]php
URL http[:]//bslines[.]xyz/copy/five/fre[.]php
URL http[:]//dewakartu[.]info/wp-includes/BRVMFYvIR/
URL http[:]//dewarejeki[.]info/wp-includes/up58jauc-pum2w-630352/
URL https[:]//healing-yui223[.]com/cgi-sys/suspendedpage[.]cgi
URL http[:]//109[.]236[.]109[.]159/vnx8v
URL http[:]//www[.]drhuzaifa[.]com/wp-includes/2i48k7-evv28gw-205510/
URL http[:]//85[.]96[.]49[.]152/6oU9ipBIjTSU1
URL https[:]//urbanandruraldesign[.]com[.]au/cdcgov/files/
URL http[:]//198[.]23[.]200[.]241/~power13/.xoiaspxo/fre.php
URL http[:]//helpvan[.]su/
URL http[:]//erasmus-plius[.]tomasjs[.]com/wp-admin/KfesPCcG/
URL https[:]//share[.]dmca[.]gripe/jUuWPW6ONwL1Wkux[.]bin
URL https[:]//gocycle[.]com[.]au/cdcgov/files/
URL https[:]//onthefx[.]com/cd[.]php
URL http[:]//186[.]10[.]98[.]177/faHtH2y
URL http[:]//dewakartu[.]info/wp-includes/BRVMFYvIR/
URL http[:]//drhuzaifa[.]com/wp-includes/2i48k7-evv28gw-205510/
URL http[:]//dewarejeki[.]info/wp-includes/up58jauc-pum2w-630352/
URL http[:]//erasmus-plius[.]tomasjs[.]com/wp-admin/KfesPCcG/
URL http[:]//easytogets[.]com/xfxvqq/UXbKAbm/
URL http[:]//dw[.]adyboh[.]com
URL http[:]//wy[.]adyboh[.]com
URL http[:]//feb[.]kkooppt[.]com
URL http[:]//compdate[.]my03[.]com
URL http[:]//jocoly[.]esvnpe[.]com
URL http[:]//bmy[.]hqoohoa[.]com
URL http[:]//bur[.]vueleslie[.]com
URL http[:]//wind[.]windmilldrops[.]com
URL http[:]//vahlallha[.]duckdns[.]org
URL http[:]//cloud-security[.]ggpht[.]ml
URL http[:]//kbfvzoboss[.]bid

 

Recommendation

This section contains some recommendations which we encourage you to follow. In addition, please also read the following blog also provides some guidance for organizations that have a workforce working remotely and about how McAfee Unified Cloud Edge can help.

Software Updates

As with all our publications, we encourage all our customers to keep their McAfee software up to date. This ensures that you will have the latest signatures and rules to help protect against similar threats to the ones mentioned in this report.

We also recommend installing the latest OS patches, VPN Patches and all other software updates on your machine. In addition we highly recommend utilizing SASE solutions such as McAfee’s Unified Cloud Edge.

Spotting Spam/Phishing emails

The best way to protect yourself is to not open unsolicited emails as malicious files are often distributed via email with the use of attachments or links. To help identify malicious emails, please read this blog: How to Spot Phishing Lures

Global Threat Intelligence (GTI)

McAfee GTI uses heuristics and file reputations checks on suspicious files through on-access scanning and on-demand scanning. This can provide near real time protection. The following KB Article contains the steps for changing the GTI sensitivity level on McAfee products.

You can configure the sensitivity level that McAfee GTI uses when it determines if a detected sample is malware. The McAfee GTI sensitivity level is set to Medium by default. Configure the sensitivity level for each scanner in the On-Access Scan and On-Demand Scan settings.

Sensitivity Level:

  • Very low — High confidence detections. Less aggressive GTI Setting, also least FP prone.
  • Low — This setting is the minimum recommendation for systems with a strong security footprint.
  • Medium — default setting on most products.
  • High — Use this setting for deployment to systems or areas which are regularly infected.
  • Very high — Most aggressive. Detections found with this level are presumed malicious but haven’t been fully tested. McAfee recommends using this level for systems that require highest security but may also result in higher false positive rate.

Endpoint Security (ENS) Product

ENS is our Endpoint Security product and provides a broad range of default protection, self-help protection and detection abilities.

Expert Rules

Expert Rules are text-based custom rules that can be created in the Exploit Prevention policy in ENS Threat Prevention 10.5.3 and above.

Expert Rules provide additional parameters and allow much more flexibility than the custom rules that can be created in the Access Protection policy. It also allows system administration to control / monitor an endpoint system at a very granular level. This is a very useful toolkit for administrators and SOC’s and allow quick creation and deployment of powerful extensions to detect and protect ability. You can author monitoring and blocking for processes, files, memory injection, module load and unload events, etc.

We recommend reading the following blog which describes how to use Expert Rules and gives some good examples which would help block potentially malicious activity.

 

Here are some examples of quick expert rules you can formulate to utilize at your endpoint against Covid-19 related threats

Example Rule – 1

The following rule helps block archived corona named executables accessed from inside archived email attachments

Rule {

Process {

Include OBJECT_NAME { -v “**” }

}

Target {

Match PROCESS {

Include OBJECT_NAME { -v “**\\appdata\\Local\\temp\\Rar*\\*corona*.exe” }

Include OBJECT_NAME { -v “**\\appdata\\Local\\temp\\Rar*\\*covid*.exe” }

Include -access “CREATE”

}

}

}

 

Example Rule – 2

The following rule helps block COVID named document containing macros accessed from email attachments or downloaded locations

Rule {

Process {

Include OBJECT_NAME { -v “**\\winword.exe” }

Include PROCESS_CMD_LINE { -v “**corona**” }

Include PROCESS_CMD_LINE { -v “**covid**” }

}

Target {

Match SECTION {

Include OBJECT_NAME { -v “**\\vbe7.dll” }

Include OBJECT_NAME { -v “**\\vbe7intl.dll” }

}

}

}

 

Example Rule – 3

The following Expert rule prevents certain version of Foobar Communication software from executing.

Rule {

Process {

Include OBJECT_NAME { -v “**” }

}

Target {

Match PROCESS {

Include DESCRIPTION { -v “FooBar Communications ” }

Include VERSION { -v “4,5,**” }

Include -access “CREATE”

 

}

}

}

 

Expert rules are flexible that the SOC analyst / author can test the rules in report only mode and then check for potential falses in the environment. Finally, they can be turned on to block mode.

JTI Rules

JTI Rules are released fortnightly and they target suspicious process chains and command-line threats. They also additionally detect suspicious files based on locations / characteristics. From the collection of JTI rules, we recommend turning on the few of Evaluate or HighOn rules for advanced threat protection. These rules can be turned default on from the EPO console.

  • Protection from suspicious Command line parameters where malware invokes PowerShell with command-line parameters for malicious activities. This rule is identifiable in the EPO console with the rule id 262.
    • Rule:262 – Identify suspicious command parameter execution for Security rule group assignments
  • Protection from malware launching suspicious command-line based script applications like WScript, CScript, and PowerShell. This rule is identifiable in the EPO console with the rule id 320.
    • Rule:320 – Prevent cmd.exe from launching other script interpreters such as CScript or PowerShell by default only in Security rule group assignments
  • Protection from files being executed from non-standard locations like \windows\fonts or \windows\resources location. This rule also protects spawning of wmiprvse.exe from suspicious process’s like foobar.exe, etc. This rule is identifiable in the EPO console with the rule id 238
    • Rule 238 – Identify abuse of common process’s spawned from non-standard locations

Fortnightly released JTI rules are normally released in Evaluate or HighOn setting. We recommend EPO admins to go through the release notes of the product and enable rules that suits their environment.

Enable AMSI

AMSI by default is set to observe mode. We recommend changing this to block mode as it will detect a vast majority of threats which are often email based such a JavaScript downloaders.

Please read this blog to find out more about AMSI and which threats it helps detect.

Suspicious Email attachment detection

As shown in this report, Email remains a top vector for attackers.  McAfee endpoint products use a combination of product features and content for increased agility.  In McAfee Endpoint Security (ENS) 10.5 and above, such protection is enabled via the ‘Detect suspicious email attachments’ option and maintained through DAT content.  This capability goes beyond the level of protection offered by email clients by not only blocking applications and scripts, but also a variety of threat types in their native form, as well as those compressed and contained within archives and other formats.

For a guide on how to enable this please read this blog: McAfee Protects Against Suspicious Email Attachements

ATP (Adaptive Threat Protection)

McAfee ATP (Adaptive Threat Protection) utilizes Machine Learning via our Real Protect Module. This provides pre and post execution monitoring of threats using ML models that are deployed locally and in the cloud. In addition, ATP provides and additional layer of protection with advanced rules for threat evaluation based on static and behavioral features.

We recommend enabling Real Protect at the default settings at the minimum. ATP rules come in three forms: Evaluate, DefaultOn and HighOn.

  • Evaluate rules are tested in the field by McAfee to determine if they are robust enough to detect malicious activity. They do not block by default but log activity in the ATP log. Such rules can be enabled by administrators via EPO to Block. McAfee researchers on a regular basis analyze performance of such rules and make modifications to promote them to DefaultOn (Rule Assignment to Balanced (default)) or HighOn (Rule Assignment to Security). Prior to manual enablement for Block mode, it is recommended that you observe triggers via the ATP logs to ensure they suite your environment.
  • DefaultOn rules are high confidence rules that block by default within ENS ATP and MVISION Endpoint. They can be turned off if required by administrators from within EPO.
  • HighOn rules detect behavior that is known to be malicious but may have some overlap with non-malicious applications. These rules work as Evaluate in balanced posture but act as DefaultOn in Security posture. Administrators are encouraged to utilize this setting to during high malware activity events for monitoring and default blocking.

For details on Rule descriptions, security posture and settings please refer this KB Article: https://kc.mcafee.com/corporate/index?page=content&id=KB82925

Unified Cloud Edge

Get a SASE (Secure Access Service Edge) architected web protection solution like McAfee’s Unified Cloud Edge. This delivers anytime/anywhere protection (like WFH scenarios) for web traffic, cloud-native and cloud-to-cloud traffic – whether you’re on a VPN, or directly connected to the internet. As an example, even if you access a link from a malicious email or visit a hostile site in a non-VPN setting, you will continue to benefit from our GTI and cloud-based threat to protect against malicious sites and downloads. Unified Cloud Edge can expand your capabilities for URL protection by providing the following:

  1. Malicious URL – blocked via GTI and URL
  2. Block any download from a benign URL (example: onedrive.live.com) – possible to block via tenant restrictions. For example: corporate Onedrive permitted, personal (live.com) or other companies blocked.
  3. Malicious download – blocked by the cloud gateway file engines, including AV, GAM, and GTI.
  4. 3rd party Malicious upload (placing a payload in an open share on the company Onedrive) – blocked via API-based scanning of the corporate sanctioned services, same AV/GAM/GTI layers of inspection.

MVISION Unified Cloud Edge protects data from device to cloud and prevents cloud-native threats that are invisible to the corporate network. This creates a secure environment for the adoption of cloud services, enabling cloud access from any device and allowing ultimate workforce productivity.

Conclusion

As you can see from this report, there are various threats which are taking advantage of this pandemic. We will continue to enable our customers to use our recommendations to remain safe during this challenging time. Be extra vigilant online and stay safe and healthy always!

As we continually provide recommendations based on current data, we encourage regular reading of McAfee blogs where you will find regular updates on threat patterns and protection information.

The post COVID-19 – Malware Makes Hay During a Pandemic appeared first on McAfee Blog.

Cybercriminals Actively Exploiting RDP to Target Remote Organizations

7 May 2020 at 04:01

The COVID-19 pandemic has prompted many companies to enable their employees to work remotely and, in a large number of cases, on a global scale. A key component of enabling remote work and allowing employees to access internal corporate resources remotely is Remote Desktop Protocol (RDP), which allows communication with a remote system. In order to maintain business continuity, it is very likely that many organizations brought systems online quickly with minimal security checks in place, giving attackers the opportunity to enter them with ease.

RDP is a Microsoft protocol running on port 3389 that can be utilized by users requiring remote access to internal systems. Most of the time, RDP runs on Windows servers and hosts services such as web servers or file servers, for example. In some cases, it is also connected to industrial control systems.

RDP ports are often exposed to the Internet, which makes them particularly interesting for attackers. In fact, accessing an RDP box can allow an attacker access to an entire network, which can generally be used as an entry point for spreading malware, or other criminal activities.

As it can be such a powerful entry vector, McAfee Advanced Threat Research (ATR) has observed many underground markets emerge, offering RPD credentials at relatively low cost. For example, McAfee ATR uncovered access linked to a major international airport that could be bought for only US$10. Since March 2020, the number of exposed RDP ports have increased considerably.

McAfee Advanced Threat Research and the security industry have been aware of the risk of exposed RDP for many years and will continue to raise awareness as part of our global threat monitoring.

In this blog, we will discuss the risks of exposing the RDP protocol and the associated misconfigurations.

RDP Statistics

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. A simple search on Shodan reveals the number of RDP ports exposed to the Internet by country.

 

It is interesting to note that the number of RDP systems exposed is much higher for China and the United States.

Most of the compromised systems using RDP are running Windows Server but we also notice other operating systems, such as Windows 7.

For attackers, access to a remote system can allow them to perform several criminal actions such as:

  • Spreading spam: Using a legitimate system for sending spam is very convenient. Some systems are sold especially for this purpose.
  • Spreading malware: A compromised system provides a ready-to-use machine for easily distributing malware, or even pivoting to the internal network. Many ransomware authors use this vector to target organizations around the world. Another criminal option would be to implant a cryptominer.
  • Using the compromised box as their own: Cybercriminals also use remotely compromised systems to hide their tracks by, for example, compiling their tools on the machine.
  • Abuse: The remote system can also be used to carry out additional fraud such as identity theft or the collection of personal information.

This recent increase in the number of systems using RDP over the Internet has also influenced the underground. McAfee ATR has noticed an increase in both the number of attacks against RDP ports and in the volume of RDP credentials sold on underground markets.

As observed on Shodan, the number of exposed systems is higher for China (37% of total) and the United States (37% of total), so it is interesting to note that the number of stolen RDP credentials from the US (4% of the total) for sale is comparatively much lower than other nations. We believe this may be because the actors behind the market sometimes hold back RDP credentials without publishing their whole list.

How are Attackers Breaching Remote Systems?

Weak passwords remain one of the common points of entry. Attackers can easily use brute force attacks to gain access. In the below image we see the 20 most used passwords in RDP. We built this list based on information on weak passwords shared by a friendly Law Enforcement Agency from taken down RDP shops.

The diagram below demonstrates the number of compromised systems using the top 10 passwords. What is most shocking is the large number of vulnerable RDP systems that did not even have a password.

The RDP protocol also suffers from vulnerabilities and needs patching. Last year, we explained in detail the workings of the BlueKeep vulnerability that affects reserved channel 31, which is part of the protocol functionality, to allow remote code execution.

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/

In early January, additional flaws related to Remote Desktop Gateway were also patched:

These two vulnerabilities are similar to the BlueKeep vulnerability and allow remote code execution by sending a specially crafted request. We have not yet observed this vulnerability exploited in the wild.

To secure the RDP protocol, the following checklist can be a good starting point:

  • Do not allow RDP connections over the open Internet
  • Use complex passwords as well as multi-factor authentication
  • Lock out users and block or timeout IPs that have too many failed logon attempts
  • Use an RDP gateway
  • Limit Domain Admin account access
  • Minimize the number of local admins
  • Use a firewall to restrict access
  • Enable restricted Admin mode
  • Enable Network Level Authentication (NLA)
  • Ensure that local administrator accounts are unique and restrict the users who can logon using RDP
  • Consider placement within the network
  • Consider using an account-naming convention that does not reveal organizational information

For more details about how to secure RDP access, you can refer to our previous blog (https://www.mcafee.com/blogs/other-blogs/mcafee-labs/rdp-security-explained/)

Conclusion

As we discussed, RDP remains one of the most used vectors to breach into organizations. For attackers, this is a simple solution to quickly perform malicious activities such as malware, spam spreading or other types of crime.

There is currently a whole business around RDP on the underground market and the current situation has amplified this behavior. To stay protected, it is essential to follow best security practices, starting with the basics, such as using strong passwords and patching vulnerabilities.

McAfee ATR is actively monitoring threats and will continue to update you on this blog and its social networking channels.

The post Cybercriminals Actively Exploiting RDP to Target Remote Organizations appeared first on McAfee Blog.

❌
❌