Normal view

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

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.

Tales From the Trenches; a Lockbit Ransomware Story

Co-authored by Marc RiveroLopez.

In collaboration with Northwave

As we highlighted previously across two blogs, targeted ransomware attacks have increased massively over the past months. In our first article, we discussed the growing pattern of targeted ransomware attacks where the primary infection stage is often an info-stealer kind of malware used to gain credentials/access to determine if the target would be valuable for a ransomware attack. In the second part, we described the reconnaissance phase of an attacker that controls an infected host or a valid account to access a remote service. Many of them are using a similar manual modus operandi as we highlighted in the earlier blogs.

We believe there is real opportunity to learn from incident response cases and previous attacks, hence why this blog is dubbed ‘tales from the trenches’. In collaboration with Northwave, this article describes a real-life case of a targeted ransomware attack. During one of their recent incident responses, Northwave encountered a relatively new family of ransomware called LockBit performing a targeted attack. First sighted in late 2019, under the name .abcd virus, this piece of ransomware was more a revision than evolution when compared with earlier attacks. Like the previous posts in this blog series, we describe the different stages of the attack and recovery, including a thorough analysis of the ransomware and the attackers behind it.

In this blog we’ll cover:

LockBit Telemetry Map

We gathered telemetry through our McAfee Global Threat Intelligence GTI database on the different LockBit samples we analyzed in our research. The global spread is currently limited as this ransomware is relatively new and heavily targeted.

Figure 1: Telemetry map

Initial Access

As in all ransomware cases, the attacker has to gain initial access to the network somehow. In this particular case the attacker performed a brute force attack on a web server containing an outdated VPN service. Based on our research it took several days for the brute force to crack the password of the ‘Administrator’ account. With this account, belonging to the administrator group, the attacker immediately obtained the proverbial “keys to the kingdom” with all the necessary permissions to perform a successful attack. Unfortunately, this is not a unique case; external facing systems should always have multi-factor authentication enabled when possible. Besides, a security organization should have a least privilege strategy when it comes to accessing systems. Targeted ransomware attackers are successfully leveraging the “human factor” integrally. It is no longer the typical “end-user clicking on a malicious link” causing the complete lock-up of a company. The human factor in targeted ransomware attacks goes much deeper. Attackers successfully leverage weaknesses in security policy and misconfigurations across an entire organization; from end-user to Domain Administrator.

Infiltrating the Network

To infiltrate the network, the attacker had to take several steps to make sure the ransomware attack was successful. An attacker always wants to infect as many systems as possible to effectively halt the business process and urge the victim to pay the ransom.

Credentials & Privileges

As mentioned previously, the attacker was successful in guessing the password of the Administrator account using a brute force attack. With this, the attacker immediately had all the necessary privileges for deploying the ransomware successfully. In other cases, as we described in our second blog, the attacker often uses known post-exploitation frameworks, for privilege escalation, lateral movement and performing any additional actions on their objective. Since quite a few of these frameworks are readily available we often call this the “GitHubification” of attack tools. In this case however, the attacker could actually skip this step and continue with the network reconnaissance and deployment of the ransomware immediately, since a high privileged account was already compromised.

Lateral Movement

With the administrator-level account, the attacker used SMB to perform network reconnaissance, resulting in an overview of accessible hosts. Subsequently, the attacker used the internal Microsoft Remote Access Server (RAS) to access these systems using either the administrator or the LocalSystem account. The LocalSystem account is a built-in Windows account. It is the most authoritative account on a Windows local instance (more potent than any admin account). Using these accounts, the attacker owned these systems and could do anything they wanted, including turning off any end-point security products. Interestingly, both the lateral movement and the deployment of the ransomware was entirely automated.

Deployment of the Ransomware

This specific case was a classic hit and run. After gaining access to the initial system using the brute-forced administrator account, the attacker logged in and deployed the ransomware almost immediately. For the attacker, this was a relatively straightforward process since the ransomware spreads itself. The deployment of the ransomware on one single host remotely instructed the other hosts in the network to run the following PowerShell command:

Figure 2: PowerShell execution to download LockBit

This command retrieves a .png file from a website that has probably been compromised. There are two versions of the .png file, one for .NET version 4 and one for version 3.5. The PowerShell command checks which version it needs by getting the version number of the common language runtime that is running the current process. If this starts with ‘V4’, the .png for version 4 is downloaded; otherwise it downloads the .png for version 3.5 via the URLs below:

  • https://espet[.]se/images/rs35.png
  • https://espet[.]se/images/rs40.png

What is interesting in this case is that each distinct host downloads the ransomware itself. Hence, the attacker only needed access to one system with an account having enough privileges to automatically make all other hosts in the network download and execute it.

Malware Analysis

For our analysis, we will use the file found in our investigation, the details of which are:

  File name: rs35.png
SHA1 488e532e55100da68eaeee30ba342cc05810e296
SHA256 ca57455fd148754bf443a2c8b06dc2a295f014b071e3990dd99916250d21bc75
size 546.00 KB
PDB c:\users\user\work\code\dotnet\regedit-64\regedit-64\obj\release\rs35.pdb
guid 84e7065-65fe-4bae-a122-f967584e31db

Technical Analysis

The file we found in our investigation was a dropper renamed as a .png file. When first opening the .png files we were expecting a real image file, with perhaps some steganography inside, but what we saw instead was the header of a portable executable, so no steganography pictures this time. The PE was compiled in Microsoft Visual C# v7.0 / Basic .NET, .NET executable -> Microsoft.

Figure 3: Static analysis of LockBit

Entropy-wise it seems quite tidy too, not showing any stray sections or big spikes in the graph. This behavior indicates that the writer of the malware did not use obfuscation.

Figure 4: Entropy analysis

Figure 5: Portex visualization of LockBit

This file is a .NET launcher. Examining the Main() function in the code shows that an array containing a particularly long AES encrypted base64 string (in the variable named ‘exeBuffer’) carries the executable for the actual ransomware.

Figure 6: .NET launcher buffer

This encrypted string is decrypted using the key ENCRYPTION29942. The first 32 bytes of the long ExeBuffer string are used as the salt in the encryption scheme, where ENCRYPTION29942 is the passphrase.

Figure 7: Launcher calls & functions

Remarkably, the script checks for the existence of vbc.exe on its designated host. Usually, this binary is a digitally signed executable from Microsoft; however, in this case, the malware uses it for process hollowing.

By statically analyzing the file we can spot the usage of:

  • NtUnmapViewOfSection
    • LockBit uses this API in order to unmap the original code in execution
  • NtWriteVirtualMemory
    • The malware writes the base address of the injected image into the PEB via NtWriteVirtualMemory
  • VirtualAllocEx
    • To allocate the space before injecting the malicious code

The VBC utility is the visual basic compiler for Windows and LockBit uses it to compile and execute the code on the fly directly in execution. If the vbc utility does not exist on the system, the malware downloads the original vbc.exe file from the same malicious URL as seen before. After executing vbc.exe, the malware replaces the objects in memory with the code for deploying the ransomware (as deduced from the exeBuffer).

Figure 8: If VBC does not exist, the launcher will download it

Payload Analysis

Analysis of the exeBuffer shows several appealing elements. It starts with a UAC Bypass via {3E5FC7F9-9A51-4367-9063-A120244FBEC7} exploiting the ICMLuaUtil elevated COM Interface-Object[1], as seen in other ransomware families like Trickbot and MedusaLocker.

Subsequently, the script uses another variant of the UAC Bypass. The CLSID {D2E7041B-2927-42fb-8E9F-7CE93B6DC937} refers to the ColorDataProxy COM Object which is classified as the same Bypass method in hfiref0x’s UACME #43[2].

In order to be stealthier, LockBit ransomware loads its modules dynamically instead of having them hardcoded in the IAT and uses LoadLibraryA. This method is employed to avoid detection by static engines.

Figure 9. Name of the modules in the code

In execution, the malware accesses the Service Manager using the function “OpenSCManagerA” and saves the handle. It checks if it fails the last error with the “GetLastError” function, against the error ERROR_ACCESS_DENIED.

Figure 10. Access to the Service Manager

Upon access to the Service Manager, LockBit creates a thread to manage services, terminate processes and delete the shadow volumes plus the contents of the recycle bin.

In this thread the malware has the name of services that it will try to manage hardcoded to try to make them more obfuscated:

Figure 11. Hardcoded service names

The list of services LockBit tries to stop are:

  • DefWatch (Symantec Antivirus)
  • ccEvtMgr (Norton AntiVirus Event Manager)
  • ccSetMgr (Common Client Settings Manager Service of Symantec)
  • SavRoam (Symantec Antivirus)
  • sqlserv
  • sqlagent
  • sqladhlp
  • Culserver
  • RTVscan (Symantec Antivirus Program)
  • sqlbrowser
  • SQLADHLP
  • QBIDPService (QuickBooksby Intuit.)
  • QuickBoooks.FCS (QuickBooksby Intuit.)
  • QBCFMonitorService (QuickBooksby Intuit.)
  • sqlwriter
  • msmdsrv (Microsoft SQL Server Analysis or Microsoft SQL Server)
  • tomcat6 (Apache Tomcat)
  • zhundongfangyu (this belongs to the 360 security product from Qihoo company)
  • vmware-usbarbitator64
  • vmware-converter
  • dbsrv12 (Creates, modifies, and deletes SQL Anywhere services.)
  • dbeng8 (Sybase’s Adaptive Server Anywhere version 8 database program)
  • wrapper (Java Service?)

If one of these services is found by the malware querying the status of it, with the function “QueryServiceStatusEx”, LockBit will get all the depending modules when correct and safe and it will stop the service with the function “ControlService”.

Figure 12. Stopping target service

LockBit will prepare Unicode obfuscated strings that contain a command to delete the shadow volumes and disable the protections in the next boot of the system.

Figure 13. Prepare the commands to delete shadow volumes and disable protections on boot

The malware has these strings in the rdata section, as widely observed in all malware families, and in its own code as show in the previous screenshots. The malware uses both strings.

During its execution, LockBit will create a snapshot of the processes running in the system and will search to see if certain processes are part of this list with the function “OpenProcess” and, in case the process is present, it will finish it with the “TerminateProcess” function.

The list of processes that LockBit will check are:

wxServer wxServerView
sqlservr RAgui
supervise Culture
RTVScan DefWatch
sqlbrowser winword
QBW32 QBDBMgr
qbupdate QBCFMonitorService
axlbridge QBIDPService
httpd fdlauncher
MsDtSrvr tomcat6
zhudongfangyu vmware-usbarbitator64
vmware-converter dbsrv12

This “process check function” is performed through a trick using the “PathRemoveExtensionA” function and removing the .exe extension from the list. Using this technique, the check process is more obfuscated.

Figure 14. Remove extension and check the process name

In our analysis, we saw how the ransomware dynamically uses the function “IsWow64Process” to check if the victim OS is running a x64 system and then uses the functions “Wow64DisableWow64FsRedirection” and “Wow64RevertWow64FsResdirection”. If the malware can access the functions, it will use the first to destroy all shadow volumes and the protections of the OS in the next boot and, later, will recover the redirection with the other function. In the case that it cannot get these functions, LockBit will delete the shadow volume directly through the function “ShellExecuteA” or with the function “CreateProcessA”.

Deletion of files within the recycle bin is executed with the function “SHEmptyRecycleBinW”.

Figure 15. Delete the contents of the recycle bin

Static analysis of the sample shows that LockBit will check the machine to see if it has support for  AES instructions in the processor with the “cpuid” opcode.

Figure 16. Check for AES instruction support in the CPU

Another check made by the ransomware is for the existence of the SS2 set of instructions:

Figure 17. Check for SSE2 instructions in the CPU

After finishing this process, the malware will try to delete itself with the next command using “ShellExecuteExW”:

Image 18. Auto-deletion of the malware

The Ransom Note

The ransom note is rather compact because the author hardcoded the content right in the code without using any obfuscation or encryption. The text file containing the ransom note is created in every directory after encryption and called Restore-My-Files.txt.

Figure 19: Content that is placed in Restore-My-Files.txt

Victim Information Stored in the Registry Key

LockBit in execution will create two keys in the infected system with the values full and public.

Those keys are created in the following hive HKEY_CURRENT_USER\SOFTWARE\LockBit. The data stored in these keys belongs to the infected victim in order to be able to identify them in the future.

Figure 20: LockBit registry keys

Lastly, after finishing the encryption, the desktop wallpaper is changed to a message for the user, saying that LockBit encrypted the host.

Figure 21: LockBit wallpaper after encryption

LockBit Filemarker

Some of the ransomware we analyzed shares a common file marker across all the encrypted files in order to verify the origin. This digital marker can be used there in the control panel in order to verify that this was the ransomware that encrypted the files.

This is an example for the first version of LockBit, where file marker was using:

C8 41 D0 BE AB 3F 0D 59 7B BF CF 40 C8 81 63 CD

If we compare two encrypted files, we can spot how the file marker matches in both encrypted files:

Figure 22: File marker used by LockBit

SMB Spreading

Analyzing LockBit in our environment, we identified the possibility to spread locally in the same local network. Analyzing the network traffic, we spotted the use of multiple ARP requests to find other hosts in the same network segment.

Figure 23: LockBit ARP traffic captured in the analysis

If these ARP requests finally find a host alive, LockBit will start a legitimate SMB connection to be able to deploy the ransomware in other machines.

Figure 24: LockBit SMB traffic captured in the analysis

If the SMB connection is successful, LockBit will execute the following PowerShell command to download the .NET launcher that will decompress and execute LockBit in a new system:

LockBit Ransomware Evolution:

LockBit is new on the scene, but we noticed the authors added several new features and improved the ransomware several times. That means there is an active group behind it which is probably getting feedback on its actions. This is an example of the development cycle; this graph was extracted, analyzing statically all the internal functions and comparing them across the samples:

For this investigation, we found different LockBit versions with different features between them:

LockBit Version 1

This first version contains unique features compared to other versions we found in the wild.

These features are:

  • IPLO (IPLogger geolocalization service)
  • Persistence through the COM interface and the HIVE Current Version Run
  • A different extension used in the encrypted files
  • Debug file created for debugging purposes
  • HIGH CPU Usage in the encryption process
  • The reusage of a MUTEX observed in other ransomware families

IPLO.RU geo-localization service:

One of the interesting items we found was that LockBit tries to identify the victim’s geo-location, through the URL IPLO.RU, requesting a static TXT file in that service.

Figure 25: LockBit IPLO.RU geolocation traffic captured in the analysis

The communication to this page is through HTTPS; we intercepted the traffic to get the reply from the remote server:

Figure 26: SSL decrypted traffic

Analyzing statically the code in LockBit, we found that this URL is not resolved dynamically in execution; it is hardcoded in the binary:

Figure 27: Hardcoded URL of IPLO service

Creating persistence through Current version Run and COM task schedule:

There are many ways to gain persistence in a system. This first version of LockBit uses a task schedule through the COM interface to gain persistence.

Figure 28: Persistence using the COM interface

LockBit also uses a reboot persistence method by using the Windows registry hive:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

Using the CurrentVersion\Run hive serves to survive the reboot if the system shuts down.

LockBit is actually using two persistence methods, CLSID and CurrentVersion\Run

.abcd extension used:

The first version of LockBit uses the .abcd extension every time it encrypts a file; this is a unique difference between this version and the other versions found.

Ransom note used:

LockBit in this first version used a different ransom note with a different message:

Figure 29: LockBit ransomware note

Debug file created in execution:

LockBit’s first version has some files that are skipped in the encryption process and every time it skips one it will create resultlog6.reg with the log information:

Figure 30: Debug file created by LockBit

High CPU usage:

We analyzed the performance of the encryption and we noted how LockBit uses the CPU heavily in the encryption process:

Figure 31: LockBit performance in execution

PhobosImposter static MUTEX used:

In October 2019, the community saw how PhobosImposter was using the mutex XO1XADpO01 in its executions and the same mutex is used by LockBit in this first version. We analyzed the base code of both samples and we did not find any code overlap but is a quite a random string to use casually.

This is the function used to create the mutex:

Figure 32. Creation and check of the hardcoded mutex

LockBit Version 2

This LockBit version came out with the following changes:

  • Appended extension changed
  • The debug function removed
  • Some of the samples came packed wither with UPX or a Delphi packer
  • One sample digitally signed

Appended extension changed:

For this version, LockBit started to append the extension .lockbit in all the encrypted files as a file marker:

Debug log function removed:

LockBit, in this new version, removed the functionality whereby it stored all the skipped files in the encryption process.

Sample delivery with different protections:

In this version we found LockBit samples packed in UPX and other custom packers, adding certain protections to the samples:

  • Extensive usage of PEB during the execution
  • The use of IsDebuggerPresent, OutputDebugString and GetLastError

All these protections are enabled by the use of packers in the delivery.

Mutex change:

The prior version of LockBit used a static mutex in all the encryptions but, in this release, it changed to be a dynamic value for every infection.

Samples digitally signed:

For all the versions we found for LockBit, only this version had a sample digitally signed:

Figure 33: LockBit sample digitally signed

LockBit Version 3

Ransomware note changed:

For this version LockBit adapted the ransomware note and used a new one:

Figure 34: LockBit 2nd version of the ransomware note

LockBit debug enabled:

After all the hunting progress we made, we found several samples of LockBit with some kind of status feature enabled, showing a progress window during the encryption:

Figure 35: LockBit debug enabled

This mode was only available for certain sample compilations and the status screen was different depending on the LockBit sample analyzed:

Figure 36: LockBit sample digitally signed

Tales from the Underground

When we researched the underground community for LockBit we came across a posting on several popular underground forums.  A threat actor named Lockbi or LockBit is offering LockBit as a “bespoke” ransomware as a service for limited partners/affiliates. We suspect LockBit ransomware to be more “bespoke”, not only from its own announcements, but subsequently we have not seen any affiliate identifiers present in the ransomware, which is normally a clear sign of an actor trying to upscale operations and service a larger number of affiliates.

The advertisement provides a general description that matches the LockBit behavior we have seen in the wild and from our analysis. As many other cyber-criminal services, LockBit does not allow the use of the software in any of the CIS countries. This is commonly done to avoid prosecution if the threat actor resides in one of those nations.

What we also noticed was a mention around multi-threading. Ransomware families are often programmed to run multi-threaded to ensure quick and overall encryption and prevent the encryption process getting stuck on a large file. However, LockBit was specifically advertised as single threaded and the threat actor Lockbi ensures that there are no speed issues when it comes to its encryption capability.

Figure 37: The LockBit advertisement

In the advertisement it is listed that one of the features of the ransomware is a local subnet scanner and SMB propagation method, something we can confirm based on our analysis.

Also noteworthy is the use of a Jabber-bot to perform the essential functions, such as chatting, decryption and banning, replacing the need for a labor intensive admin panel that is hosted somewhere on the internet.

Figure 38: LockBit profile including the 10,5 BTC deposit

It seems that LockBit has joined the underground scene with a clear determination to do business; the authors have put a down a deposit in excess of 10,5 BTC, a bit shy of 75K USD. Putting a deposit in escrow is a way to demonstrate that the seller is invested financially and not out to scam potential partners. The seller would lose their deposit if they did not keep to their end of the deal. Our telemetry shows that LockBit activity is still limited today but we can definitely expect to see more bespoke LockBit attacks in the near future.

Recovery

Going back to the real-life case, there were no recent offline backups. So, with the backup servers (including the backups) encrypted as well and a complete rebuild not being an option, there was no way for a successful and swift recovery other than by paying the ransom.

Both McAfee’s and Northwave’s perspective is that ransoms should not be paid. Paying does not only support the criminal business model, but as we have shown in our research, it also finances other forms of crime, such as the online drug trade.

In this specific case the victim chose to pay the ransom. The first step for recovery was to get in contact with the hacker following the instructions from the ransom note (Restore-my-files.txt) as depicted below.

Figure 39: LockBit ransomware note

Interestingly, as opposed to earlier known cases of LockBit (or .abcd virus) where contact with the attacker occurred via email addresses mentioned in the ransom note, in this case, the attacker developed an online ‘help desk’ accessible via a .onion address. Helpful as the hacker is, they even provided clear instructions on how to access this .onion address with the Tor browser. Although the ransom note claims there was private data obtained, Northwave did not find any evidence for this on the compromised systems.

Figure 40: LockBit recovery page

The image above shows the helpdesk which the attacker uses for communication with their victims. It provides the functionality for a trial in which two files can be decrypted ‘for warranty’, showing that the attacker indeed has the correct key(s) for restoring the data. For this, it is always essential to test files from different (critical) servers since keys might differ per server. In negotiations with an attacker, always try to obtain this knowledge since it is also relevant for your recovery strategy. If it is only one key, you know you can use one tool for the entire network; however, if encrypted servers use distinct keys, recovery becomes increasingly more difficult.

After successful decryption of two different files (from distinct servers), the chat with the attacker began. They started by asking for a network domain name (to identify the correct victim), then the attacker addressed the ransom amount. Usually, the attackers do proper research on their victims and tailor the ransom amount accordingly, which was the case here as well. Hence, negotiating on the amount of the ransom did not prove to be useful:

“We know who you are, so don’t play negotiate games.”

Trouble in Hacker Paradise

Subsequently, making the bitcoin transaction to the provided address, the helpdesk page would automatically update after six confirmations and show the download link for the decryptor.

“After 6 transaction confirmations, in a few hours decryptor will be built automatically. Don’t worry you will get it instantly once it’s built.”

Since there was nothing else to do than wait and hope for the decryptor now, an attempt was made into obtaining some more information from the attacker by asking about their methods. See a snippet of this conversation below.

Figure 41: Attacker communication

The ‘weak passwords’ is, of course, entirely in line with the brute force attack mentioned earlier. Additionally, this conversation indicates that there is a larger group behind this attack, where roles between different participants are separated. The helpdesk seems to be an actual helpdesk, merely following a script of actions.

After waiting for several hours and six confirmations further, the decryption tool should have been ready for download. However, this is where things progressed differently. There seemed to be some technical issues causing the decryptor not to generate automatically for which the helpdesk kindly apologized. Unfortunately, this continued for two dubious days with multiple excuses before the attacker sent a link to the decryptor via the chat. It appeared that they were ineffective in solving the technical issues; hence they chose to send it via SendSpace.

Once downloaded, the recovery phase could start. In this phase, all servers were decrypted, scanned and cleaned (or rebuilt) in a quarantined network. Subsequently, after implementing the appropriate technical and security measures, each host joined a new clean network.

Conclusion

As we highlighted in the first two articles, targeted ransomware attacks have increased massively over the past months. Many of them are all using a similar, quite manual, attack pattern as we highlighted. In this article, we provided an in-depth view of a relatively new ransomware family named LockBit. Based on a real-life case as encountered by Northwave, we described a typical ransomware attack including the modus operandi of attackers, the recovery process, an insight in the underground that advertises the ransomware and a full technical break-down of the ransomware itself. Additionally, during our analysis, we were able to obtain multiple samples of the LockBit ransomware with which we could provide an extensive list of IOCs. McAfee will continue monitoring this threat.

Learn from the articles, identify which technology can give you visibility inside your network. What digital evidence sources do you have, and can you detect fast enough to preserve and respond? If you were not able to prevent the ‘initial access stage’, make sure to have a strong Defense-in-Depth by having multiple defence technologies in place. In case a ransomware attack does strike your organization, have a proper backup procedure in place to successfully restore operations on your own? For additional ransomware prevention tips please visit www.NoMoreRansom.org.

To learn more about how McAfee products can defend against these types of attacks, visit see our blog on how ENS 10.7 Rolls Back the Curtain on Ransomware.

MITRE TAXONOMY

Technique ID Technique Description
T1107 File Deletion
T1055 Process Injection
T1112 Modify Registry
T1215 Kernel Modules and Extensions
T1060 Registry Run Keys / Start Folder
T1179 Hooking
T1055 Process Injection
T1179 Hooking
T1124 System Time Discovery
T1046 Network Service Scanning
T1083 File and Directory Discovery
T1016 System Network Configuration Discovery
T1012 Query Registry
T1082 System Information Discovery
T1057 Process Discovery
T1063 Security Software Discovery
T1047 Windows Management Instrumentation
T1035 Service Execution
T1075 Pass the Hash

IOC’s

SHA256 Compile TimeStamp
ffbb6c4d8d704a530bdd557890f367ad904c09c03f53fda5615a7208a0ea3e4d 1992:06:20
286bffaa9c81abfb938fe65be198770c38115cdec95865a241f913769e9bfd3f 2009:02:12
76a77def28acf51b2b7cdcbfaa182fe5726dd3f9e891682a4efc3226640b9c78 2009:02:12
faa3453ceb1bd4e5b0b10171eaa908e56e7275173178010fcc323fdea67a6869 2009:02:12
70cb1a8cb4259b72b704e81349c2ad5ac60cd1254a810ef68757f8c9409e3ea6 2019:11:29
ec88f821d22e5553afb94b4834f91ecdedeb27d9ebfd882a7d8f33b5f12ac38d 2019:12:01
13849c0c923bfed5ab37224d59e2d12e3e72f97dc7f539136ae09484cbe8e5e0 2019:12:11
6fedf83e76d76c59c8ad0da4c5af28f23a12119779f793fd253231b5e3b00a1a 2019:12:17
c8205792fbc0a5efc6b8f0f2257514990bfaa987768c4839d413dd10721e8871 2019:12:18
15a7d528587ffc860f038bb5be5e90b79060fbba5948766d9f8aa46381ccde8a 2020:01:23
0f5d71496ab540c3395cfc024778a7ac5c6b5418f165cc753ea2b2befbd42d51 2020:01:23
0e66029132a885143b87b1e49e32663a52737bbff4ab96186e9e5e829aa2915f 2020:01:23
410c884d883ebe2172507b5eadd10bc8a2ae2564ba0d33b1e84e5f3c22bd3677 2020:02:12
e3f236e4aeb73f8f8f0caebe46f53abbb2f71fa4b266a34ab50e01933709e877 2020:02:16
0f178bc093b6b9d25924a85d9a7dde64592215599733e83e3bbc6df219564335 2020:02:16
1b109db549dd0bf64cadafec575b5895690760c7180a4edbf0c5296766162f18 2020:02:17
26b6a9fecfc9d4b4b2c2ff02885b257721687e6b820f72cf2e66c1cae2675739 2020:02:17
69d9dd7fdd88f33e2343fb391ba063a65fe5ffbe649da1c5083ec4a67c525997 2020:02:17
0a937d4fe8aa6cb947b95841c490d73e452a3cafcd92645afc353006786aba76 2020:02:17
1e3bf358c76f4030ffc4437d5fcd80c54bd91b361abb43a4fa6340e62d986770 2020:02:17
5072678821b490853eff0a97191f262c4e8404984dd8d5be1151fef437ca26db 2020:02:20
ca57455fd148754bf443a2c8b06dc2a295f014b071e3990dd99916250d21bc75 2020-02-20

 

The post Tales From the Trenches; a Lockbit Ransomware Story appeared first on McAfee Blog.

MalBus Actor Changed Market from Google Play to ONE Store

9 April 2020 at 17:38

Authored by: Sang Ryol Ryu and Chanung Pak

McAfee Mobile Research team has found another variant of MalBus on an education application, developed by a South Korean developer. In the previous Malbus case, the author distributed the malware through Google Play, but new variants are distributed via the ONE Store in much the same way. ONE Store is a joint venture by the country’s three major telecom companies and is a preinstalled app on most Android phones selling in South Korea. It has 35 million users (close to 70% of South Korea’s population) and has already surpassed Apple’s app store sales from the end of 2018.

The application in question is distributed via Google Play and the ONE Store at the same time. The malicious application downloads and runs an encrypted payload with malicious functions.

McAfee Mobile Security detects this threat as Android/Malbus and alerts mobile users if it is present, while protecting them from any data loss.

Figure 1. Screen capture from the application page on the ONE Store

The Campaign

We found malicious code injected by an attacker, via the developer’s account, into versions 27 and 28 of the application distributed through the ONE Store. The App Signature Certificate for versions 26 through 29 distributed from the One Store are the same. No other application developed by the same author was found on the ONE Store. The ONE Store is now servicing version 29 which does not contain malicious code. Google Play still offers version 26, though this is also clear of infection.

Figure 2. Infected version history of the application

The overall flow of this application, focusing on the malicious function, is explained below:

Figure 3. Overview of malicious behavior

After the malware is installed, the malicious code has a latent period of 10 hours to avoid being discovered by dynamic analysis.

Figure 4. Using LastUpdateTime to check latent period

After the latent period, it starts two threads. The first one loads native library “libmovie.so” and calls one of its exported functions, “playMovie”, with a phone number as an argument while the second one creates a Java server socket for communication with another native library.

Figure 5. The malicious native library embedded in the APK

The first loaded library, libmovie.so, contains a curl binary and URLs for secondary payloads in XOR encoded data which are decoded at runtime. The XOR value is 0x8E and it is globally used in this library. All decoded URLs appear to have been hacked and the decoded URLs drop RC4 encrypted ELF files.

 

Table 1. Contents in libmovie.so

Simply put, libmovie.so is a downloader and executer. It downloads the next payload from a hacked web server by using a dropped curl binary, decrypts it and loads the library. Once the library is loaded, the downloaded file is deleted to avoid detection. Lastly, the downloaded code starts from exported function name “Libfunc”.

Figure 6. The main flow of libmovie.so

As for the RC4 cryptographic library, encryption is the most common way to hide or protect important things. Accordingly, it is assumed that there is some important in this file.

Table 2. Additional information of downloaded file

The file sizes and data for szServer_XX_1 and szServer_XX_2 are the same as shown in Table 2. But szServer_XX_3 has several functions that are added, removed or modified a little bit. However, it does not affect the overall process.

“doMainProc” is the core function called by “Libfunc”. The first job of the “doMainProc” is selecting the C2 server randomly.

Table 3. C2 server list

After selecting the C2 server, a randomly created TUID is sent to the server. Guessing from its usage, the TUID might be a target device ID to manage contaminated targets. Now the application is working as a spy agent, waiting for actions from the selected server and ready to execute commands. We discovered the following available commands:

 

Table 4. Available command list

Among the malicious commands, an eye-catching feature is SMS and MMS capturing. SMS and MMS are saved in the “/data/data/<package name>/files/” directory as file name “sms.txt” and “mms.txt” respectively.

Figure 7. SMS and MMS are saved in txt files

This feature can be activated by registering the Android receiver.

Figure 8. RegisterReceiver

This malicious app opens TCP port 1111 locally to communicate with the loaded native library. Below is manually interpreted Java code:

public void run()

{

CommunicationThread commThread;

Socket socket = null;

serverSocket = new ServerSocket(sock_port); // sock_port = 1111

if (serverSocket) {

while ((!Thread.currentThread().isInterrupted())) {

commThread = new CommunicationThread(this, serverSocket.accept());

new Thread(commThread).start();

}

}

}

Figure 9. com.joojang.CharacterClassic.MainService

The SMS/MMS capture feature is enabled when receiving a “SET” string on local TCP 1111 port and disabled by receiving “FREE”.

Figure 10. SET or FREE

The loaded native library connects when the “SD_SetSMSCapture” command receives and sends “SET”

Figure 11. SD_SetSmsCapture

Below is interpreted as C language.

client = socket(AF_INET, SOCK_STREAM, 0);

addr.sin_family = AF_INET;

addr.sin_port = htons(1111);

addr.sin_addr.s_addr= inet_addr(“127.0.0.1”);

One other function we have not seen before is “SD_LoadSoFile”. This loads a new native library and executes a specific function in it. This function seems to change the running native library to a newer one when the current binary has a problem, or to add new features.

Figure 12. SD_LoadSoFile

Compared to Malbus

This newly discovered malicious code has many similarities compared to Malbus, such as using the same malicious function name starting with “SD_”, file name, XOR’ed strings to hide original strings, embedded files in libraries, command ids, the same version of compiler and so on. It also has the differences mentioned above: downloading a malicious library directly instead of installing a plugin APK and no sensitive keyword list such as ‘North Korea’, ‘National Defense’ and so on.

Figure 13. The identical function names from the malicious library

Figure 14. The same version of compiler strings

Conclusion

Malware can be distributed through all manner of third-party app stores, not only official ones such as Google Play. This malware is carefully prepared – the final payload of the malware is the file that was hacked and uploaded to the vulnerable server before malware distribution. We believe the authors of this malware will continue to buy or hack trusted developer accounts to update malicious functionality, infiltrate and distribute through official app stores. As with previous cases, users should verify the applications they install, even if they download them from official stores. McAfee is working with Korean law enforcement agencies to help with the takedown of the attack campaign.

 

Hashes (SHA-256)

Initial Downloader (APKs)

  • 5e57bc8d83a372bf4d046c272cd43db9000036c9b32d8eecead1af75f4958c57
  • 1613b35c73c6497730490d7712ac015c2b42931446aed149e1292e2ba77d0ff4

Encrypted Trojan (additional payload)

  • d328373cd67c467485b9c96349a0ee08fc3b58fe2c11fb19f4dcb9ea6c7a0dae
  • c5bff68022ead6302f710f1ce1c3d5682a8cd3610b1f8ed2563098d7ac4e1909
  • c410cacbb0be8f649f082148c91f4cef27f101b8db3ce64a02882506c9b51a63
  • 178dddf38ec232d540bd88320521d8134644da1e7af19e7ae295b2d614e3ab56

Decrypted Trojan (additional payload)

  • 9fc914545fbb99b7e0d4a5207f5a2b32a8a127a36caa9159d4feeac445c509f7
  • df651ac1bfd60cd29cea85cc410002b933552260c2439fe86a4f32486abd0828
  • 63d10c9cd105c7b17effef18d31d571fe4c9c999966cc09bdb40df07c1b6baa8
  • f99212b70729942923fe26b996791cdd8eb561f8ae017e1d71202fbb97f7d245

The post MalBus Actor Changed Market from Google Play to ONE Store appeared first on McAfee Blog.

Transitioning to a Mass Remote Workforce – We Must Verify Before Trusting

7 April 2020 at 13:01

While not a new practice, the sheer volume of people required to adhere to social distancing best practices means we now have a mass workforce working remotely. Most enterprises and SMBs can support working remotely today but many IT departments are not equipped to scale to the numbers currently required. In this blog we discuss the threats to enterprises and SMBs through this increased remote workforce and how to mitigate the risk.

Cybercriminals seek opportunities to achieve their goals and will follow the path of least resistance. The initial access vectors enumerated in MITRE ATT&CK typically used by cyber criminals are phishing or exploitation of vulnerabilities to gain access to an organization, and are used to act on their malicious objectives. Now that employees have migrated to their homes to work remotely, cybercriminals will target the insecurities of consumer systems and networks to gain access to corporations. As Raj Samani highlighted in a previous post, targeted ransomware attacks are fueling the increased demand in the underground for compromised corporate networks. If employees access corporate networks from pre-infected unmanaged machines without adequate security measures, it creates a much larger attack surface for cybercriminals. This increases the risk of an organization falling victim to a potential breach and ransomware lockdown.

COVID-19 social distancing restrictions came into effect very rapidly, giving organizations little time to prepare for securely managing their workforce remotely. It is important that organizations continue to do business during this tough time, but they must also do it securely to prevent an attack such as ransomware. To protect organizations in this current climate we must approach this from two perspectives:

  1. Know your environment and users
  2. Know your business and real threats

To understand the threats of telecommuting at scale, we must understand the technologies typically used by remote workers to execute their work and access the organization.

Know Your Environment and Users

Per figure 1 below, it is important to understand the architecture and technologies being used by your employees within your business environment. This gives you visibility into your potential exposure based on vulnerabilities being actively exploited by threat actors so that you can protect your remote workers and business infrastructure/assets.

 

Trust boundaries, common technologies and use cases in telecommuter deployments

Know Your Business and Real Threats

Adversary Opportunities

Adversaries need an initial access vector to gain a foothold within an organization. They will typically seek out corporate usernames and passwords using techniques enumerated in MITRE ATT&CK, such as phishing or remote exploitation of software vulnerabilities. The telecommuter technology increases the attack surface significantly and is being exploited/researched as evident below:

Controls

Minimum technical controls for remote worker machines:

  • Secure configuration and strong passwords to prevent router compromise
  • Keep all software layers patched, VPNs and telecommuter applications
  • Do not reuse passwords across personal and work systems
  • Robust endpoint security software

Minimum technical controls for enterprise/SMBs:

  • Security hygiene best practices
  • MFA/2FA and logging for VPN accounts
  • VPN patching
  • Secure RDP access
  • Segmentation of critical business assets
  • Data backups
  • User and device identity for employees and 3rd parties/suppliers

Policies:

  • Data loss prevention
  • Strong passwords
  • SaaS security
  • Managed vs unmanaged device access

Training:

  • Phishing and social engineering training based on the current climate context – “verify before trusting”
  • Keep employees informed of phishing campaigns relative to your environment and business

Conclusion

Strong technical controls are a must to protect telecommuters in the current climate and there is also no substitute for employee phishing and social engineering training as a successful phish can negate technical controls. Even MFA/2FA can be bypassed in some cases, using advanced phishing techniques, so we must all stay vigilant, starting with ourselves to protect our organizations by adopting a “verify before trusting” approach.

The post Transitioning to a Mass Remote Workforce – We Must Verify Before Trusting appeared first on McAfee Blog.

COVID-19 Threat Update – now includes Blood for Sale

7 April 2020 at 13:01

Although the use of global events as a vehicle to drive digital crime is hardly surprising, the current outbreak of COVID-19 has revealed a multitude of vectors, including one in particular that is somewhat out of the ordinary. In a sea of offers for face masks, a recent posting on a dark web forum reveals the sale of blood from an individual claiming to have recovered from Coronavirus.

What are we doing?

Putting our customers at the core is what McAfee does. Daily updates are provided to products across the McAfee portfolio, with vetted information to secure your valuable assets in company or working from home.

The volume of threats related to COVID-19 has been significant, with lures used in all manner of attacks. Tracking these campaigns reveals the most targeted sector is healthcare, followed by finance, and then education.

Mobile Threats

In March 2020 alone, McAfee Labs identified several malicious Android applications abusing keywords connected to the pandemic. The apps range from ransomware samples to spy-agents that spy on the victim’s device. For example, statically analyzing an app called “Corona Safety Mask,” we observe that the amount of permissions is suspicious:

  • Full Internet access that allows the app to create network sockets
  • Read contact data from the victim’s device
  • Send SMS messages

When the user downloads the app, it can order a facemask from the following site: coronasafetymask.tk. The SMS send permission is abused to send the scam to the victim’s contact list.

Although attribution will clearly be a key concern it is not the primary focus of our research, however there appears to be APT groups incorporating  the COVID-19 theme into their campaigns. For example, spreading documents that talk about the pandemic and are weaponized with malicious macro-code to download malware to the victim’s system.

Underground Marketplaces and scams

We have seen many examples of major events being abused by people whose interest is only financial gain and current global events are no exception. We conducted a short survey on some underground markets and Telegram channels offering protective masks and more. Two examples are shown below:

Onion-site offering masks
Telegram channel with multiple sellers of masks

The use of COVID-19 as a lure does not appear to show any sign of slowing down, indeed there are more campaigns being regularly identified using the global concern for selfish gain. Our focus will be to ensure detection remains up to date, and data points relevant for investigation are shared with authorities.

In the meantime, we will continue to disseminate relevant threat information. To be kept up-to-date as we publish more content,  stay connected to the McAfee Labs Twitter feed.

Finally, while COVID-19 related threats are on the rise, from phishing emails name-dropping the disease to malware named after popular video conferencing services, cybercrime in all aspects continues, and we must remain vigilant to other, traditional threats as well. For example, tips to secure the newly massive mobile workforce can be found here.

Please stay safe.

The post COVID-19 Threat Update – now includes Blood for Sale appeared first on McAfee Blog.

Nemty Ransomware – Learning by Doing

2 April 2020 at 18:21

Executive Summary

The McAfee Advanced Threat Research Team (ATR) observed a new ransomware family named ‘Nemty’ on 20 August 2019.

We are in an era where ransomware developers face multiple struggles, from the great work done by the security community to protect against their malware, to initiatives such as the No More Ransom project that offer some victims a way to decrypt their files. Not only that, but the underground criminal community around such ransomware developers can also be hyper critical, calling out bad code and choosing not to purchase ransomware that is not professionally developed.

After one such developer, going by the name jsworm, announced Nemty on underground forums, we noted how the ransomware was not well received by some users in the criminal community. Certain sectors of that forum started to rebuke jsworm for technical decisions made about the functions in the ransomware, as well as the encryption mechanism used.

Jsworm replied to all the comments, adding evidence about how the critical statements made were wrong and showcased the value of their new versions. They also fixed some ugly bugs revealed by users in the forum:

One of the users in the forum highlighted a function for how Nemty detects extension dupes in a system, which needed to be re-written by the author:

Despite the shortcomings in their ransomware, the Nemty developers are still in the underground forum, releasing new samples and infecting users through their affiliate program.

Telemetry

Based on our telemetry, we have seen Nemty activity in these locations:

FIGURE 1. Telemetry Map

Nemty Technical Analysis

Nemty runs on a Ransomware-as-a-Service (RaaS) model. We’ve observed it being delivered using:

  • RIG Exploit Kit in September 2019
  • Paypal dummy sites
  • RDP attacks through affiliates in their campaigns
  • Botnet: Distributed through Phorpiex botnet in November 2019
  • Loader: SmokeBot

FIGURE 2. Nemty ransomware announcement

In the release announcement the Nemty developers offered two types of collaboration: affiliation or private partnership. We found two aliases advertising Nemty, one of which is jsworm, who is quite active in the forums and announces all the news and updates there.

This is the timeline of the operations performed by the Nemty crew:

We observed how the Nemty developers adopted some characteristics from other old ransomware families like the defunct Gandcrab. One example of this is the reuse and reference to a URL that leads to an image featuring Russian text and a picture of the Russian president, like Gandcrab had in its code.

FIGURE 3. Hardcoded URL inside the Nemty ransomware pointing to the same image as GandCrab

The Nemty authors released different versions of their ransomware. In this research article we will highlight how the first version works and the significant changes added in subsequent versions.

Hash:                    505c0ca5ad0552cce9e047c27120c681ddce127d13afa8a8ad96761b2487191b

Compile Time:    2019-08-20 19:13:54

Version:                1.0

The malware sample is a 32-bit binary. The packer and malware are written in the C/C++ language as the author announced on the underground forum.

The compilation date in the PE header is the 20th of August 2019.

FIGURE 4. EXEInfo Image

Nemty uses RunPE in execution, meaning it unpacks in memory before execution.

Analyzing the sample, we could find how the developer added certain protections to their code, such as:

  • Decrypting certain information in the memory only if the encryption process is working as planned
  • Clearing the memory after finishing some operations
  • Information sharing between different memory addresses, cleaning the previous memory space used

Ransomware Note Creation Process

In order to create the ransomware note, Nemty takes each string and saves it into memory. When the ransomware compiles all the required strings it will join them together to create the entire ransomware note. In this operation, Nemty will decrypt line by line, moving the data to another memory address and cleaning the previous one to leave the information only in the new memory space.

For the first version of Nemty, the encryption method was not applied consistently to all the strings, which is why it is possible to see some strings and spot part of the functionalities or juicy files from them.

FIGURE 5. Clear strings in Nemty

Nemty and the Logical Units

In execution, Nemty will check all the logical units available in the system, saving the information about them in a static list with the following information:

  • Type of unit
  • Available free space

Through the use of the Windows API, ‘GetDriveTypeA’, the ransomware will differentiate units between:

  • Removable
  • Fixed
  • Network

FIGURE 6. Checking the type of logic units

To check the free space available in the system, Nemty will use “GetDiskFreeSpaceExA”, again through the Windows API:

FIGURE 7. Checking free disk space

Extracting Public IP Address from the Victim

Since the first version, Nemty has implemented a functionality to extract the public IP address of the victim. The information is extracted through a request to the IPIFY service at http://api.ipify.org. These types of services are frequently used by RaaS to check the location where the victim was infected.

FIGURE 8. Nemty getting the public IP

The User-agent for some of the Nemty versions was the ‘Chrome’ string. The user-agent is hardcoded as a single string in the ransomware instead of using an original user-agent.

FIGURE 9. Getting the IP address of the victim machine

The IPIFY service is used to retrieve the public IP address of the victim and, with the extracted data, Nemty makes another connection to http://api.db-api.com/v2/free/countryName using the data previously obtained as an argument. The extracted IP address and country data is used later used as a part of the ransomware note creation.

FIGURE 10. Getting the country name strings based on the IP address

Victim Information Extraction

Nemty will extract the following information from the victim:

  • Username
    • Using the windows API GetUserNameA
  • Computer name
    • Using the windows API GetComputerNameA
  • Hardware profile
    • Using the windows API GetCurrentHwProfileA

With this data, the authors ensure that the infected victim is unique, which helps the RaaS operators quantify how many victims they were able to infect themselves or through the use of affiliates.

FIGURE 11. Get Username, Computer Name and Hardware Profile from the victim machine

Nemty 1.0, Wrongly Applying the Country Protection

RaaS families usually apply some protections to prevent infecting certain geographic regions. In the first version, Nemty still had this feature in development as our analysis showed that the ransomware did not check whether the victim belonged to any of the supposed blacklisted countries. During our analysis of ransomware it is quite usual to find functions that are still in development and are then incorporated in future versions.

If the detected country is in the blacklist, Nemty returns the string “true” and keeps it in the config. If the country is not found, the value of the field will be false.

FIGURE 12. Check the country name and return true or false string

Nemty Encryption Keys

Immediately after making this check, Nemty will decode, from base64, the value of the master key and keep it in a memory address to use later. In parallel, it will prepare a random string with a fixed size of 7 characters and use it with the string “_NEMTY_” to create the ransomware note with the specific extension used in the encrypted files. Nemty will create a pair of RSA keys, one public and one private, in this process.

FIGURE 13. Export public RSA and private keys

Within this operation, Nemty will encode those keys in base64:

FIGURE 14. Encode of RSA keys generated

After this encoding, Nemty will decode again the victim RSA public key and import it for later use.

FIGURE 15. Decoding of the RSA public key for later use

The same operation is again used but this time with the master RSA public key from the ransomware developers.

Nemty Encryption Keys

In the encryption process, with all the data collected from the user, Nemty will create their config file, all in memory. The config file is a JSON structured file with all the collected data and the AES key previously created. Regarding the key used, it is the same for all of the files, however Nemty uses a different IV for each file.

Nemty Configuration File:

An example of the information collected by Nemty and later used in the config file can be found below:

This is an example Nemty configuration file:

FIGURE 16. Nemty config file

The different fields for the configuration file are:

The configuration file will be saved on the disk encrypted with a RSA public key of 8192 bits and encoded in base64.

FIGURE 17. Crypt the config file and encode in base64

Nemty will get the username logged in the system through ‘SHGetFolderPathW’ and will save and encrypt it with the .nemty extension on that folder.

FIGURE 18. Getting the user’s root folder

FIGURE 19. Creation of the config file on the disk

Nemty Encryption Threads

For the encryption, Nemty will create a new thread per each logic unit found in the system in order to encrypt the files.

The method used to encrypt the files is similar to other RaaS families, getting all the files using the function ‘FindFirstFileW’ and ‘FindNextFileW. Nemty will avoid encrypting folders with the following names:

  • .
  • ..

The encryption process will also avoid using files with the following names:

FIGURE 20. Check of the blacklisted folder and file names

This check is done using the insensitive function “lstrcmpiW”. Where Nemty is encrypting a file it will try two combinations, one in lower case, one in uppercase.

The extensions checked are:

 

FIGURE 21. Check of the file extensions

If Nemty has successful checks, it will create a random IV and encrypt part of the file with the AES keys previously generated. It then begins the IV using the victim’s RSA public key and appends it to the encrypted file.

FIGURE 22. Write the crypted file and put the IV in it

Nemty will put the information required to decrypt the file in the encrypted part of it and then add the extension “.nemty” and continue with the next folder or file.

FIGURE 23. Renaming of the new file with the Nemty extension

After finishing the encryption process Nemty will use the function ‘WaitForSingleObjects’ and wait for all the pending threads. It will also download the Tor Browser and open a connection in the loopback with the configuration file.

As a final action, Nemty will execute the command prompt of the machine with the hardcoded word “cmd.exe” and open the ransomware note.

FIGURE 24. Opening the ransom note

The style of the ransomware note changed across the different versions that the Nemty developers released.

FIGURE 25. Different ransom notes between versions

On the left side, we can see Nemty version 1.4. On the right side, the ransomware note belongs to Nemty version 1.0.

Like other ransomware families, Nemty will perform these actions at the end:

  • Delete the shadow copies using vssadmin
  • Disable boot protections with bcedit and wbadmin
  • Delete the Windows catalog with WMIC using the class shadow copy

All these calls are made with the function “ShellExecuteA” with the “cmd.exe” string as the main program and the other as an argument.

FIGURE 26. Deletion of the shadow volumes, disabling boot protections, and deleting the catalog

Mutex

Nemty will create a specific mutex in the system every time it infects a system:

The ransomware will check the existence of the mutex using the function “GetLastError”.

FIGURE 27. Creation of the hardcoded mutex

If the system was infected previously with Nemty and it contains the mutex, the ransomware will finish the execution using the function “ExitThread”. This call will end the main thread of the malware, finishing the execution and returning the control to the operative system.

The “ExitProcess” function is often used to avoid simple API monitoring.

Nemty uses RC4 to encrypt its strings and, in execution, those will be decrypted and decoded from base64 and then be used as a part of the ransomware note.

FIGURE 28. Calculating the size of memory to decode from base64

The RC4 key used for Nemty 1.0 is ‘f*ckav’. Other malware families also often use offensive names or expressions regarding the security industry in their implementations.

For decryption, the developers implemented a function through the API to reserve the needed space with ‘malloc’ and later decode the string in memory. As a protection, if the ransomware fails to get the size or on the decoding operation, the execution will finish using “ExitThread”.

FIGURE 29. Decrypt the data with RC4

Nemty – Learning by Doing

Since the first version of Nemty was released, the authors started to evolve their ransomware by adding new capabilities and fixing aspects of its code.

Analyzing the early versions of Nemty, we can state that they were more advanced in techniques and obfuscation compared to other RaaS families, but the first version still contained functions with some mistakes, such as references to API calls that were not used by the ransomware.

At the time we wrote this article, the developers behind the ransomware have released 9 different versions:

Changelog Nemty 1.4

We have observed changes across the different versions of Nemty. For version 1.4, the developers applied the following changes:

  • The ransomware will gather information regarding the logical units after checking if the victim has the Nemty mutex.
  • Language check
    • In this version, Nemty will respect and avoid encrypting files for victims inside the CIS countries.

FIGURE 30. Check to avoid crypting if the language is blacklisted

CHANGES IN VERSION 1.5

Compared with Nemty 1.4, this newer version was a major release, adding the following changes:

  • Victim information stored in the registry
  • Persistence
  • Ability to kill processes and services
  • New mutex
  • Hardcoded image change
  • C2 panel publicly accessible
  • 4 new blacklisted countries

Victim Information Stored in the Registry

The first major change in this version of Nemty was the use of the Windows registry to store information about the infected machine. The hive used is HKCU with the NEMTY identifier.

FIGURE 31. Information saved in the registry

Ability to Kill Processes and Services

The second feature added is the possibility to kill certain processes to facilitate file encryption in the system, something that is commonly implemented by other RaaS families.

In order to kill those processes, Nemty will use taskkill /im PROCESSNAME.

FIGURE 32. Termination of processes

Among certain kill processes, Nemty will stop certain services in the system with the same objectives:

To stop the services Nemty, will use “net stop” and the service name.

FIGURE 33. Stop of services on the victim machine

Persistence

The first versions of Nemty did not have any persistence technique, so the author decided to add it in version 1.5. The persistence is done through a scheduled task, “create /sc onlogon”. The binary is copied into the main user directory with the name hardcoded (this can be adapted for every binary released) “AdobeUpdate.exe” and the task launched using “ShellExecute”.

FIGURE 34. Creation of a schedule task to persistence

Hardcoded Image Change

Regarding the picture hardcoded in the first versions, for this version, Nemty decided to change it and include a new one.

FIGURE 35. New image referenced in the malware

C2 Panel Publicly Accessible

The author, decided to swap TOR for a public C2 panel where Nemty will send the victim’s data.

https://nemty.hk/public/gate?data=<victim_data>

4 New Blacklisted Countries

For this version, the author added four new countries to the blacklist:

Changes in Version 1.6

Compared with the previous version, Nemty in the 1.6 version only implemented one single change. The author used their own implementation of the AES algorithm instead of using the CryptoAPI.

The way that the malware previously generated the random key was based on functions of time but with version 1.6 it mostly used some other value to generate the random key.

FIGURE 36. Changes in the key generation function

One of the partners in the No More Ransom project, Tesorion, decided to publish a free decryptor for victims infected by Nemty. After the announcement, the Nemty authors released a new version utilizing a proper AES function using CryptoAPI.

FIGURE 37. New implementation of the AES crypto using CryptoAPI

Like in a game of cat and mouse, Tesorion released a new decryptor for this specific version. The Nemty authors responded by including a harcoded message to Tesorion in the samples:

Tesorion “tesorion, thanks for your article”.

Second Version of 1.6

Instead of changing the Nemty version number in this new binary, the authors released a new version of 1.6 with some changes.

The changes added for this version are:

  • New vssadmin utility used
  • New processes and services to kill
  • FakeNet feature

This new version was released just 2 days after the first 1.6 version was released; this means that the actor is quite active in developing this ransomware.

New Vssadmin Utility Used

The first change for this version is how the logical units where enumerated. The Nemty author implemented the use of the utility “vssadmin” and also reduced the capacity of the shadow volumes to 401MB. This change probably helped the ransomware in terms of performance.

FIGURE 38. Resize of the shadow volumes in the target logic unit

The idea of this change was to remain more stealthy against endpoint security products, instead of just deleting the shadow copy and executing queries through WMI, BCEDIT, etc. The author changed their approach to use vssadmin with the delete flag.

New Processes and Services to Kill

The Nemty authors added new processes to kill in order to facilitate file encryption:

In addition to new processes, the author also included new services:

FakeNET Feature

For this version the Nemty authors decided to add one interesting feature. The ransomware in execution had implemented a function to retrieve the victim’s public IP address. In the case that Nemty cannot connect with the external IP address, the ransomware will add fake data in order to continue the encryption process. The fake data will be:

 

FIGURE 39. Nemty using fake IP address and country name information if it cannot connect to the URL to get a WAN IP

This feature implemented by Nemty will expose users in the protected countries as it will encrypt the system, even if the user belongs to one of the countries specified in the static blacklist.

Version 2.0

In this version the developers decided to remove certain features and added a new encryption process:

  • The FakeNet feature was deleted and Nemty only used the old mechanism to check the victim’s region.
  • An initial function that prepares a container to use the RC4 algorithm with the name “rc4” and get a key based in the hardcoded string (can change in other samples) “sosorin :)”. This key is used to decrypt part of the ransom note and certain strings. It changes the use of the authors’ own RC4 implementation to now use the RC4 algorithm with CryptoAPI.
  • A new generation of RSA containers of keys, improving the key generation process.
  • The ransom note text included “NEMTY REVENGE” instead of “NEMTY PROJECT” and also added the sentence: “Don’t trust anyone. Even your dog”.

FIGURE 40. Nemty ransomware note

Version 2.2

For this version, the Nemty developers only made two minor changes:

  • Change of the mutex name
  • A new ransom note:

FIGURE 41. Example of the new ransom note

Version 2.3

In this version, we found major changes compared with the prior version:

  • A new mutex value
  • The service used to get the public IP changed from https://api.ipify.org to https://www.myexternalip.com/raw
    • In case the lookup fails, the external address changes from NONE to NOT_DEFINED.
  • The Windows OS check for XP was duped in prior versions and now only has one specific check.
  • The configuration fields changed, certain fields were removed and new ones were added.
    • This is an example for the new configuration file:

{

   “fileid”:”NEMTY_E1EIVPU”,

   “configid”:”mArJi2x3q3yFrbvL8EYkKezDeGPgWeOG”,

   “compid”:”{a3cande1-f85f-1341-769f-806d6172f54544}”,

   “ip”:”NONE”,

   “country”:”{    ”   “errorCode”   “: ”   “INVALID_ADDRESS”   “,    ”   “error”   “: ”   “invalid addr”   “,”   “version”   “:”   2.3   “,”   “computer_name”   “:”   “USERPC”   “,”   “username”   “:”   “User”   “,”   “os”   “:”   “Windows XP”   “,”   “pr_key”   “:”   BwIAAACkAABSU0EyAAgAAAEAAQDdTDOyFDw4+kjmmP2epZ/484E7PLyyZ5W1obSZSHWPirGeobWwqnoVTXLPbKVYXZ4qszCzO71hwFKcKjeYjX1dVzSlonqpWlU5d2XLtM+6oN9PTUIv2Fp8Quf8w3FU+0OmmS9A0s3n6cnvpA8oIJTZFgYurYDs78Gv3dt4dUkQioqyT/kWBOTZMBARqjiN6JwCCZDU4moRm+9IcqiXzUydebF99EoHxKcJrAekIHuHbHzZq/FcVogFSHT+4aV2/NTrESiNLeLYWv0S/GJrYs2xoLLe3NpdW7disE/PY1yn4flWGPU931AWy4/ba8+bjRXr1UPCKFk370oqWesemfK8j694toexJlRYc8s1mql2T6gq/NnqsWIxgR2B4Esn3xMzXcGZD86mA+XO/gZWgZw9kyJ4rzonWiF8OMWznKgmC0n4rxoOh70eE0m15LPkJOJwmBcVoHE189R71titoNMEYZsK8/WE0x8YJjAAdxmI4ATufV1ZUDbO7yOf5Tc5UuHTxu5iUOL0dO004Hh0t6SZIxbjUbtlHhJTiUULL+TpyG9YP1LyNMhKDE80viN9Co/a6xbs6IRhxhRRFthtHE/kRBeYfhptCblWOStLebtrNgwfe8f3AR2XdH6uESiQ8rTXG/dSgXOfmUQzuvSbxdL4aQ5docbtjQlMEl/FqYqs1pGTEB+cBATRoeY97LSCr/ZvhQPUVPyAD0NHKPOUawrGtXyiAYP3WWhKOQFM1nqQ1E9Mf38NHbaQtNJ8s/BOvMxra2Q9AaCd34IGz3uZuEZIqqXx2qqchHoHPFvopBnkCiJThmb0PoUHsA4keC7EIv3To038Wg2GYhfzy6+vwEIx01F02xhZSHjSUlSmYM2YiS4FZu2F02L49tUPIueqo3ON2ts+G/z36kkaBFocPRJjQGL2cUmG0jI0kdahL6uNYfUL3Cu261bmxewxS1eSk+cb2zC5OckuwxoT66ZddRF+Ud2K2SIPV3oMy3D/4oUtsrAEUv2inEthtwvY8FdzzsM1KlcvLszggKHRdTe4a3hf9ALU7omy3avhGaCtznhRnZvD0W1QNKyKRYBCtHc7e30EpbYtQ8kxRBrrQfySsQMDPfagETSDQMRdD0lLmNCsaJJqS9s7CnsXuTedTiOZA7Nddrc/qUceeZ7ZXMvwhpQJ6TglLJ/qCMFz6u63biGhCi38BxVRhrFzMIV4wEHlmw/7ZKiIsE49XvWzJJH3J6cgvw8XGysgS29w8McqSVaucPhw+lONwc8SLTqDwZ78ozJmr3Hq4bWFjlMSeo/H8tzr++eVMAwNiiECWo2/i2WwraBG7/jpwtedjQF576tBE6TEvriVjohjyhAYj0SprtJoqS5kX6NVM8c8GaeVKbcUp6bPqZLlGi1yfP0dhgpnR81SfDVuv/RaLPedYPfKL3hK1g6UbRJvENVgrr5tik8TLley6v73MI1pbWmEnr48Zk8Y6bb4fm0H9OvkiDYmDDTh4I49TNEyuw8eD8auJ6CsapZUTmvqMlrGI3rnjueTdjQ=   “,”   “drives”   “:[{”   “drive_type”   “:”   “FIXED”   “,”   “drive_letter”   “:”   “C”:”/”   “,”   “total_size”   “:”   9GB   “,”   “used_size”   “:”   9GB   “},{”   “drive_type”   “:”   “NETWORK”   “,”   “drive_letter”   “:”   “E”:”/”   “,”   “total_size”   “:”   9GB   “,”   “used_size”   “:”   9GB   “\”}]}”

 

  • The User-agent changed to a new one, “Naruto Uzumake”.
  • Concatenating a lot of taskkill commands through the use of “ShellExecuteA”; this version of Nemty kills a lot of new processes.

FIGURE 42. Killing processes with CMD

  • For this version, the authors added PowerShell executions using a command prompt with the function “ShellExecuteA” :

FIGURE 43. Launching a PowerShell command

  • This version added a new subkey in the registry key “Run” in the hive HKEY_CURRENT_USER with the name “daite drobovik”:

FIGURE 44. Creating persistence

  • The ransom note was again changed for this version:

FIGURE 45. Example of the ransom note in version 2.3

Version 2.4

This version was a minor release like Nemty 2.2. In our analysis we only noted changes for the ransom note:

FIGURE 46. Example of the ransom note in version 2.4

Version 2.5

This is the last version of Nemty we discovered. This one represents a minor release and we only spotted two changes for this version:

  • A new mutex value
  • A new ransom note:

FIGURE 47. Example of the ransom note in version 2.5

Relationship between JSWORM and Nemty

Our Advanced Threat Research (ATR) team followed the activity of the user jsworm in the underground forums, and uncovered another piece of their ransomware, called JSWORM ransomware. Below is an announcement they made on the same forum on which they presented Nemty:

FIGURE 48. JSWORM ransomware and Nemty announcement

We analyzed all the samples we had of JSWORM and Nemty and could not find any relationship in the code base between them, but it is clear that both pieces of ransomware belong to the same moniker.

HASH FAMILY Compilation timestamp
0b33471bbd9fbbf08983eff34ee4ddc9 Nemty 2019-08-29 08:31:32
0e0b7b238a06a2a37a4de06a5ab5e615 Nemty 2019-08-19 04:34:25
27699778d2d27872f99ee491460485aa JSWORM 1992-06-19 22:22:17
31adc85947ddef5ce19c401d040aee82 JSWORM 2019-07-19 05:21:52
348c3597c7d31c72ea723d5f7082ff87 Nemty 2019-08-25 11:58:28
37aaba6b18c9c1b8150dae4f1d31e97d Nemty 2019-08-20 19:13:54
4ca39c0aeb0daeb1be36173fa7c2a25e Nemty 2019-08-13 14:46:54
5126b88347c24245a9b141f76552064e Nemty 2019-08-21 16:16:54
5cc1bf6122d38de907d558ec6851377c Nemty 2019-08-21 14:27:55
74701302d6cb1e2f3874817ac499b84a JSWORM 2019-07-10 08:44:29
7def79329823f3c81a6d27d2c92460ef JSWORM 2019-07-09 18:54:23
dcec4fed3b60705eafdc5cbff4062375 Nemty 2019-08-21 19:25:16
de9e1a5fc0f0a29b97eb99542d1f297a JSWORM 2019-07-09 20:25:14
f270805668e8aecf13d27c09055bad5d Nemty 2019-08-21 18:42:10
f796af497399c256129f2ce61eb8855b JSWORM 2019-07-19 05:24:00
fbf7ba464d564dbf42699c34b239b73a JSWORM 1992-06-19 22:22:17
0f3deda483df5e5f8043ea20297d243b Nemty 2018-12-04 11:00:39

Some of the samples released contain custom packers so the compilation timestamp is not accurate for those cases.

Based on the data of the binaries we found, we can see how Nemty activity started some time after the JSWORM ramsomware disappeared. This could indicate that the threat actor jsworm was developing both pieces of ransomware at the same time.

Free Decryptor Available Through No More Ransom

One of the partners of NoMoreRansom was able to release a working version of a Nemty decryptor. If someone is affected by this ransomware, it is possible to contact them through NoMoreRansom to get a decryptor.

Nemty Releases Customer Data Publicly

In our analysis of the Nemty ransomware, we spotted a new trend in how its authors managed the data of their victims.

In this instance, much like we have seen with other ransomware families like Maze, Nemty has its own website on which customer data is publicly released.

Image source: Bleeping Computer

Conclusion

Despite the number of RaaS families that appeared this year, Nemty represents another piece to observe and follow. Since we started to watch the activities of this ransomware, the criminals behind it have released multiple new versions with bug fixes and improvements. Such activity suggests that ransomware authors are feeling pressure from the great work done by security researchers and organizations, and in the case of Nemty, even from the underground criminal community which itself was quick to criticize some of its functions and implementations.

Tesorion, now a partner in No More Ransom, released a working decryptor for Nemty and so we now expect that the author will change the ransomware again to continue their activities. The last action we observed from this group was the website shown above, created to leak customer data.

Mitre ATT&CK

The sample uses the following MITRE ATT&CK™ techniques:

Technique ID Technique Description
T1124 System Time Discovery
T1083 File and Directory Discovery
T1012 Query Registry
T1057 Process Discovery
T1047 Windows Management Instrumentation
T1035 Service Execution
T1215 Kernel Modules and Extensions
T1179 Hooking
T1112 Modify Registry
T1107 File Deletion
T1089 Disabling Security Tools
T1055 Process Injection
T1179 Hooking
T1055 Process Injection
T1132 Data Encoding

Coverage

Generic Trojan.si

GenericRXIS-SF!348C3597C7D3

GenericRXIS-SF!37AABA6B18C9

GenericRXIS-SF!5CC1BF6122D3

GenericRXIU-OJ!0B33471BBD9F

Ransom-Nemty!09F3B4E8D824

Ransom-Nemty!2FAA102585F5

Ransom-Nemty!65B07E2FD628

Ransom-Nemty!9D6722A4441B

RDN/GenDownloader.alr

RDN/Generic.fps

RDN/Generic.fqr

RDN/Generic.fry

RDN/Generic.ftv

RDN/Generic.fxs

RDN/Generic.fyy

RDN/Ransom.gg

RDN/Ransom.gn

Trojan-FRGK!484036EE8955

Indicators of Compromise

Hash PE TimeStamp
64a1ce2faa2ab624afcbbbb6f43955e116b6c170d705677dba6c4818770903aa 1992:06:20 00:22:17+02:00
c537c695843ab87903a9dbc2b9466dfbe06e8e0dde0c4703cbac0febeb79353a 1992:06:20 00:22:17+02:00
8e6f56fef6ef12a9a201cad3be2d0bca4962b2745f087da34eaa4af0bd09b75f 1992:06:20 00:22:17+02:00
ca46814881f2d6698f64f31e8390fe155b9fd0d8f50b6ab304725a2251434aa7 2009:08:13 23:36:24+01:00
5d04d789d66152e3fc0a2d84a53c3d7aa0f5d953c1a946619deeb699f3866e26 2017:01:02 12:16:24+01:00
a743d29eb16f9b4a59b2fd8c89e59053bdccce362f544fe82974e80d580c88f6 2018:03:27 07:09:32+02:00
5439452012a052851fdd0625abc4559302b9d4f4580e2ec98680e9947841d75d 2018:04:17 01:50:07+02:00
20d432c171ec17e7c5105f032210a96ea726ffc52154b79ec43acd62d6e3f304 2018:06:09 22:43:06+02:00
9fad280bb034a4683be9ab4a35d2859e61dc796a6134436b4403c2cb9a9ebfea 2018:06:09 23:45:15+00:00
7c1aaccca9dd236b9271c734d987d0fccc3e91bfa4c445c5e1c7c41e61ffe3ca 2018:06:16 17:31:40+02:00
2f2aeb72dd127057fac1eeefdc0539fc3fa7bdff36d288bd7e20f2756194253d 2018:06:16 23:24:06+02:00
6b3fea34cb8bb5cc6d698e30933884e1fe55c942d8768da85eb1c8085525bb41 2018:06:20 00:56:49+01:00
345380e840249081cba552af4ab28d7c65d4052f6e4bedd748b673b8853e6e96 2018:06:20 01:56:49+02:00
0f6e82387a5fe0f64d7cec15466b17a623aa8faaf9971df3c49ab65d49d1422e 2018:07:06 02:30:25+02:00
4b86f102eff21382c1a40a28bd4db19356e1efd323336bcec6645e68592e754a 2018:07:07 17:59:57+01:00
b604a25ae4a668170bf28bfc885d0e137f4ff3a29eb7f772ba7098ecfb9bacb3 2018:07:08 12:47:46+02:00
664b45ba61cf7e17012b22374c0c2a52a2e661e9c8c1c40982137c910095179a 2018:07:14 02:09:27+01:00
536209365d143bf90a44f063eff9254639d7976b2f77edcc2a0ff6ac1e5a5464 2018:07:23 22:32:23+02:00
e29d154b067f298bab794d9f85ee7b3d58ebf17b56f6cff6601fb6ce48482f09 2018:08:01 20:19:32+02:00
c2a32b7094f4c171a56ca9da3005e7cc30489ae9d2020a6ccb53ff02b32e0be3 2018:08:06 17:50:00+02:00
5d58c85ba5bd7a4ca3d5ade7bff08942a12399f82defa370691524d8797a1095 2018:08:09 01:11:34+02:00
c8d44e8c91ed028626a8e2b3a526627790a2ac3e7078316172e35371fb984eee 2018:08:09 01:11:34+02:00
7eb2b5125f9fbcc2672c05031456b6a2432c8921e9fa561bb7d7fa72010638b0 2018:08:22 21:17:21+01:00
06c1428e1a41c30b80a60b5b136d7cb4a8ffb2f4361919ef7f72a6babb223dd3 2018:08:22 22:17:21+02:00
66e55d3ffc0dcc4c8db135474cb8549072f8b1015742038f2ebb60d8c5dbd77c 2018:08:24 01:21:20+02:00
7fab9295f28e9a6e746420cdf39a37fe2ae3a1c668e2b3ae08c9de2de4c10024 2018:08:27 18:49:08+02:00
bf3368254c8e62f17e610273e53df6f29cccc9c679245f55f9ee7dc41343c384 2018:08:28 00:50:58+02:00
eb98285ef506aa5b6d38bbd441db692b832f7ed1b9cb1dc4e2fec45369c8432a 2018:08:29 19:54:20+02:00
676224fb3ab782fc096351c2419ebd8f7df95a9180407f725c57e72d2bbec5b1 2018:08:29 20:05:56+02:00
9b5067d5e7f7fbf52b5069f5557d5b0cf45752a6b720f5a737b412600da8c845 2018:09:07 18:40:54+02:00
30832d5709f93b16a6972fca9159fbd886a4e9815ef0f029fade5ca663e9761e 2018:09:08 01:26:36+01:00
e5527d1bfc8b1448dcd698f23ac7142a066bb19b6109ef1c92df4d6214aa2d6a 2018:09:11 22:58:35+02:00
c09272b4a547aa5e675f9da4baf70670bd192b1dfd8dd33b52a42ee83f782cac 2018:09:30 18:36:38+02:00
aa36aa7425e9591531d5dad33b7e1de7ffbe980376fc39a7961133f5df8ab31a 2018:10:03 22:27:20+02:00
a54bca66aac95cb281d313375e38cd8058ace1e07c5176995531da241c50dbd6 2018:10:06 10:02:23+02:00
63ed68751000f7004bf951bc4a4c22799a94d28602f4022d901b6558ff93b46b 2018:10:09 22:04:03+02:00
fe639627cf827e72c30992c627fffd458f7afb86d5b87e811415b87c2276e59c 2018:10:12 20:11:41+02:00
74f8c39f3b0e4338eeaabad97c9303139336be9ebe059501a78174570540eb9e 2018:10:14 01:10:44+02:00
0a472cb6772f554afc9720064a0ba286ddc02250b9249cace39b3bdd77b5265c 2018:10:20 16:38:09+02:00
0a0fb6e146bf8473b8931c3775529b2a0c8baf0db9afae7d3bb53f3d1da8c6ca 2018:10:21 23:30:07+02:00
0285a046ecaa82e685275ea53ae56134cb992991ef0d2ac5af3f5c15ebd136cc 2018:10:25 23:28:29+02:00
3d852ca618763ced2e280f0c0079e804935b70dcd4adc3912c2e2b3965e196c4 2018:11:03 16:59:21+01:00
4f3c6b42a2182b530f44d37fb82df8c2e1ca3858bfdd6d921aa363efe3e6e7bb 2018:11:03 16:59:21+01:00
3d9742b2ca3756645f88e885d1dadb2827a19f01ca6fb4a5170f2888cced35e1 2018:11:03 16:59:21+01:00
a2f6c36cb8f46207028fbd3f3b69e306d3bdc4fc0391cfda5609812df880be07 2018:11:10 17:30:47+01:00
b3dbfbd64088691b4bf07b9001890bc60ff7f95fb44acdc20d95e8dd3c72c050 2018:11:11 00:53:46+01:00
5e4a090b75ca915fc42a149c7ddfba0dbe1a6846fe3b36249923549656c31218 2018:11:25 19:51:19+01:00
a5590a987d125a8ca6629e33e3ff1f3eb7d5f41f62133025d3476e1a6e4c6130 2018:12:04 12:00:39+01:00
a7558decb9516122781243e791c982977660152813817fb7ed00359365fcb0d3 2018:12:06 17:53:43+01:00
b2c11e6126a7de326e5fef14679279bf9fa920b7ba7142984d99790d89155b69 2018:12:06 17:53:43+01:00
4379f688682395f0ebcd70acd14c304a1074928198b4d0bebb5362d56328f76e 2018:12:06 21:13:33+01:00
8dca973cccf5073a9f53f055fa275215520ba67416b5d206c673df533532efe5 2018:12:07 01:04:23+01:00
9913afe01dc4094bd3c5ff90ca27cc9e9ef7d77b6a7bdbf5f3042a8251b96325 2018:12:10 19:04:48+01:00
17864c4e21c0ebaf30cca1f35d67f46d3c3c33a5b8ea87d4c331e9d86d805965 2018:12:15 23:24:41+01:00
36bd705f58c11c22529a9299d8c0c1a33cf94fb9b7cce0a39a79e4d8f523308d 2018:12:16 21:12:50+01:00
1b18d04d4ca37ecc25bd8d4f229121c89a57c80615d40ff94868f380cdfaed7c 2018:12:24 21:33:38+01:00
b0bd94cf4f409bb5ba2661d875e0488e59492c95a539508172e2670d74feb0ea 2018:12:27 21:42:57+01:00
b9ff00a4b426742892e21601a68b19ffa44668f3274ec250e60843c3224b6b42 2018:12:30 01:14:36+01:00
4f5bb92d861601642aec31ecbd7864b2dcca9027ef3ff7256c0d12915580181b 2019:01:10 22:35:38+01:00
2a5f9e5d72b4841538a73ee2556865d8ed76e3da38571f00148368874edf55c8 2019:01:19 23:44:33+01:00
708922215acc1ddbe35a9549afce408aaa0aa74caa78feca96150e755ebf7b98 2019:02:02 11:07:14+01:00
03e46ba0d430afd4c85eaef47dcb38faf8cd7ef78ef25f8aa911c216a598245c 2019:02:02 23:01:04+01:00
cbb016cab1718c610f2bd98e0190bb5a426a2de38ddfccfec86196294e47bca0 2019:02:05 04:34:44+01:00
2ebe4c68225206161c70cf3e0da39294e9353ee295db2dc5d4f86ce7901210c5 2019:02:08 18:17:02+01:00
947bddf40d6dcf4cbbf174b2067a9f5e09fa2eb03d039974feba1d398ddeb184 2019:02:11 23:26:07+01:00
3207b5da6ecf0d6ea787c5047c1e886c0ee6342a5d79e4bcb757e7e817caa889 2019:02:16 17:40:03+01:00
ee3a8512f4109ec7a21831aee68ba53fb431d5eac613b66bf9877f50118c0cd4 2019:02:16 19:26:22+01:00
9caae99f53cc1446f04703754fa03b98a6303882e0999653c2c5fbfe656e3164 2019:02:26 00:00:02+01:00
cfe5682a41c5b4a3fd9c09070262171a05e0ce99868ef0e2058a5d65385ed681 2019:03:10 18:09:02+01:00
1ac0c87c3ff27dc6d630cb3f543311fb48edfc88d33470836438b1d388ae9687 2019:03:12 20:03:50+01:00
57a73c98866cd1aa0e57b84c0a13a54901077d23b6683d16b713d652d74fd1c7 2019:03:24 20:58:51+01:00
f2c6e0a2500876a3426b191cfbd3b65625bb182f23fda68d256f56a644f4f123 2019:04:02 11:44:51+02:00
5078a0940abc31a7fa271483ac345044a91a0e21c517bceb85091cd3fca310f7 2019:04:03 01:09:42+01:00
92981ed851493d6897339df02a77799645a0edf078daa8cf6cf09293f0801b7c 2019:04:06 02:29:49+02:00
084da93689b04f0a162bcd6fa2d43937f84182ac94d40b871d8650d89501c2bd 2019:04:10 00:40:47+01:00
e563bfae9ee7effe4c9766ded059dc2e91f7f76830973dfdadfb203c47fe8c2a 2019:04:12 17:33:50+01:00
a77beff2bf75a2a82b7c96438e9c55e2839cba2ea057892422b714876b8def58 2019:04:12 21:09:21+01:00
d341571f9b8ea62f52b9563ca1fb77bee5127a2a5b93d00682622eb116db0275 2019:04:12 22:26:26+01:00
510c0746a5d8b0175e80e2fbbbfbf194c8e20e56cccd5a9ec5fac4ad2e2f77f7 2019:04:15 19:01:48+02:00
e070a88883634bf7105f9744123adfd3890947e8da4754d2560293e68f809f10 2019:04:17 01:57:08+02:00
44c6edb224810748a0b15512a47647f5e35157fdaa30357d2820c1eb250273e4 2019:04:17 20:57:27+01:00
db25fd682243d4449c423a57591bd0d69a98f3e6149b815e6c556a76b5fbb71a 2019:04:19 19:05:12+02:00
405df2b5aa985c8386d347b6e7f269e546231a02abd1e793ae792010248bc9da 2019:04:27 00:59:44+02:00
081444b3b8b82c06c631d3106859ab530435af68292a8009c4b6eb2285cb9929 2019:04:27 22:03:27+02:00
a380640490d3aa7380255ed9269bb967a4daee6d2d20353a50154e7e6d399746 2019:04:28 23:52:25+02:00
fe244ab332b490623a8a313a8b64a1d280f3e03b2457f6c3235d01ee8f21c701 2019:04:29 00:49:00+02:00
abf148370f7cc9c16e20c30590a08f85208f4e594062c8a9e59c0c89cd8ff43f 2019:04:29 02:32:07+02:00
034b86e971f24282bd0c1b74a257c7c60ec7d83fa45ac5d5321e7c436675be89 2019:05:04 17:03:52+02:00
859e8f98203fa9b8fb68cf1e4c6f9a1143c970bd2830601841b83ee49b2a72ba 2019:05:05 22:59:32+02:00
2e436f4277a6cac69c5b484284160559752ef0679e27e2af8112e78c9074a17c 2019:05:07 23:20:09+02:00
6be9cc0bda98fee59c94d687c293b83f1b41588ca991f35328f4d56c9c1f38e4 2019:05:17 12:12:43+01:00
29ba2b8099985501ae9aafa964daeca66d964e9fbc1d0025928b49fcae0efb63 2019:05:17 12:58:42+02:00
a08dc1e27b9e92ba70dcd2bce611fa51ec3601e4a2e7cdbb7713b656160c3773 2019:05:28 21:36:33+02:00
cc496cec38bbc72bae3cb64416baca38b3706443c4f360bd4ba8300d64b210d2 2019:08:13 16:46:54+02:00
267a9dcf77c33a1af362e2080aaacc01a7ca075658beb002ab41e0712ffe066e 2019:08:19 05:34:25+01:00
505c0ca5ad0552cce9e047c27120c681ddce127d13afa8a8ad96761b2487191b 2019:08:20 20:13:54+01:00
6a07996bc77bc6fe54acc8fd8d5551a00deaea3cc48f097f18955b06098c4bd3 2019:08:21 16:27:55+02:00
d421d9b0cc9ce69fc4dea1d4bd230b666b15868e4778d227ead38b7572463253 2019:08:21 17:16:54+01:00
f854d7639a5db4c42b51aecd541aaf61879591adf42ebcba068f3b111fb61a34 2019:08:21 19:06:44+01:00
688994783ce56427f20e6e2d206e5eee009fcc157ba37737dce1b14a326cc612 2019:08:21 20:25:16+01:00
4cf87dd16d57582719a8fe6a144360f3dfa5d21196711dc140ce1a738ab9816e 2019:08:21 20:34:34+02:00
15084aa0f30f5797bd666f18d0992dfcdb1c080c8d25cf2f6d97f9166e45b93b 2019:08:31 14:06:01+01:00
7c638c17b3fc92393c421dff34a1c9245c26f9526fb20699af567e6a38535a06 2019:09:04 14:05:11+02:00
022076c2c8f1555ee98a08ff5714aa1db20e1841fe3b8d1362fed0d6bef1c87d 2019:09:19 22:32:44+02:00
fb81f82121f9604a664925790e83763f7dceb2adaa4aeafaf8af24f7986e1f12 2019:09:24 12:28:55+02:00
a41949b9cddc2838534c0f70c0a615a7135fc95e452270ff661247a60d6b638d 2019:09:24 14:55:26+01:00
3aeaf37af33b92dfa62489250ec2857d6bab1098fcf356cdb58e05efabe359cb 2019:09:27 12:59:27+02:00
9f2a0b1553f8b2e1a5c0c40023ac9abed76455cdb0f5a346601088615606eac0 2019:09:28 11:31:11+02:00
068575719283c1e33abb8530340d7ac0b4d44b15da1ee0877c03537216df3001 2019:09:30 02:31:49+02:00
9574f57f7a4192f0507fa3361fb3e00e1f1101fdd818fc8e27aaba6714cd373c 2019:10:02 17:22:33+01:00
98f260b52586edd447eaab38f113fc98b9ff6014e291c59c9cd639df48556e12 2019:10:04 09:56:21+02:00
30ad724c9b869ff9e732e95c7e3b94a0d118297c168ffd4c24bac240e0cba184 2019:10:04 13:01:21+01:00
62c3b52b5310393dbf0590bc246161249632a1d2f21c3aa7fb779dc8018a0edf 2019:10:05 03:10:25+01:00
d041cc7e2e9d8d6366b28abc0428b7d41ad75bcfb67631830a838c32e49fd365 2019:10:07 17:57:43+02:00
88fcdfd4c89a9d3108582e5746b58beda9e538f357f3b390a008a7e5925c19f5 2019:10:07 18:22:30+02:00
9b5a42c4dbb2df3e1457e8a7bdbe93a2a4b4382a4de70077ace34a3c5a04ba1f 2019:10:10 02:55:12+02:00
2497543441cf35647afa60d6bc76825cfebf24e3421fbe101b38838aed63ba21 2019:10:11 02:44:30+02:00
5e2c0b6d2f74605f11047a6b6ebff7026035471bccd3e2c6ba03df576eef08cd 2019:10:12 20:12:30+02:00
aaaa143d3636133fa952b79f3e447264a56a4db223a046906b95802e50a359f9 2019:10:25 11:04:07+02:00
0c18068dab291fcdd5a9aa94fb6cb07b8aeec1e4ecbab3746c3b0586e7bbd692 2019:10:26 06:58:37+01:00
36e66c1d562af0df6c493cb998b24f8b52da55452dce6514d92e14ee64ab41c6 2019:11:26 20:09:10+01:00
2160391fc7c69bc30dea5c4e0e3e6ca2045d021087d4f1170d74eacedae9ebd2 2019:11:26 20:09:10+01:00
b01054d750aaa982359bee75707847f30df668135ca139e25b142e18f8cf2f51 2019:11:26 20:09:10+01:00
97c5eeddaaa99a578a94609a69be099d7ac61f4d797f14a5f9a696566205366e 2019:11:26 20:09:10+01:00
c5d43698296b4e9b9f7491669b7b20ef651302593c72b827462c08c9d6e76ae3 2019:11:26 20:09:10+01:00
d5b4f6cd5c6d142cdcfeca789b58942ee01270cb52de1d0f4c8d3cb7f44fa6e4 2019:12:14 15:45:13+01:00
e04d28b43fcc11ef8869641c2795774ae139ee6ed06c295c772d8a4f2381e831 2019:12:15 09:55:10+01:00
1d3f2ba1c701ecf04c288b64d9f2470c6f58744d5284174c1cb8e8b3753f3fae 2019:12:15 09:55:10+01:00
45c3faeb8cdd2cbdcf6161f05b2e72aba7927594138da693b0020f24db9e60d8 2019:12:15 09:55:10+01:00
4402b31f717bfe82498d162adac0c9b4f5a9ca413c883ac94ab8e322c50f11db 2019:12:23 09:17:02+01:00
a3cb6814fcdb42517728815c875f2dc169ac7b15f615b971eff209c4e2937527 2019:12:23 17:10:14+01:00
0a14d4313ded36716d9de16b8487ac91b0dcf6a77c9f0c21531916c31a0a5ee9 2019:12:24 05:03:25+00:00
735ef043f3f64a9c57ba938dddc6fdac60ed30fa746a728635835c7162729710 2019:12:25 20:14:11+01:00
92cf38b5bee56490871c19e1ee31239c550a0eb6d177a37d02079465be9e4f7d 2019:12:27 18:55:35+01:00
4b4feffb0783aca42f0e9c38961340a76b4a2b3fd324f71e764a88ab500f1372 2019:12:27 18:55:35+01:00
5a022aba75d4986adedb1a5fb62fce8946d43f06846f663a851ba93e9e317f8c 2019:12:27 18:55:35+01:00
3ae7d44569b2885de360c0e6c3448772f74c1c3ff4ee3f594053a95bfc73850f 2019:12:27 18:55:35+01:00
42e9356feb10e5814fb73c6c8d702f010d4bd742e25550ae91413fa2a7e7c888 2019:12:27 18:55:35+01:00
bf6b8563773f7a05de33edcb1333d9e39e5bc60c91d111d3fb4ec7f5cfbb6c43 2019:12:28 03:06:43+01:00
842b92ed20115ff28fd5b8b204e80e88168594aa5ce44c288a560ec6f907516a 2019:12:28 03:06:43+01:00
eedefda5ff588f0b194b97a0244d6d3e4892b9a5f1539b33aa0fa86a47be7ea1 2019:12:28 03:06:43+01:00
d398280940af9fcb5aad2f0eb38d7b00b9d241ad1c4abfe3ca726accded70e2a 2019:12:29 09:38:39+01:00
6e18acc14f36010c4c07f022e853d25692687186169e50929e402c2adf2cb897 2020:01:07 10:57:37+00:00
8e056ccffad1f5315a38abf14bcd3a7b662b440bda6a0291a648edcc1819eca6 2020:01:18 12:03:36+01:00

The post Nemty Ransomware – Learning by Doing appeared first on McAfee Blog.

Ransomware Maze

26 March 2020 at 16:26

EXECUTIVE SUMMARY

The Maze ransomware, previously known in the community as “ChaCha ransomware”, was discovered on May the 29th 2019 by Jerome Segura[1].

The main goal of the ransomware is to crypt all files that it can in an infected system and then demand a ransom to recover the files. However, the most important characteristic of Maze is the threat that the malware authors give to the victims that, if they do not pay, they will release the information on the Internet[2].

This threat has not been an idle one as the files of one company were indeed released on the Internet. Even though the company sued, the damage was already done. This is a behavior increasingly observed in new ransomware[3], such as Sodinokibi, Nemty, Clop and others.

It was highlighted last year[4] how ransomware would head in this direction to obtain money from victims who may be reluctant to pay for decryption.

TELEMETRY MAP

FIGURE 1. MAP OF MAZE INFECTIONS

INTRODUCTION

On the 29th of October a campaign distributing the Maze malware to Italian users was detected. Historically, the malware has used different techniques to gain entry, mainly using exploits kits, remote desktop connections with weak passwords or via email impersonation or, as in the Italian case, via different agencies or companies[5], i.e. the Italian Revenue Agency. These emails came with a Word attachment that was using macros to run the malware in the system.

The exploit kits used most often were Fallout and Spelevo[6].

The malware is hard programmed with some tricks to prevent reversing of it and to make static analysis more difficult. This report covers these protections and the behavior of the malware in an infected system.

The developers have inserted messages to provoke malware researchers, including the email address of Lawrence Abrams, owner of “BleepingComputer”, who they contacted directly. They are very active on social media sites such as Twitter.

McAfee protects its customers against the threats that we talk about in this report in all its products, including personal antivirus, endpoint and gateway.

MAZE OVERVIEW

The malware is a binary file of 32 bits, usually packed as an EXE or a DLL file. This report focuses on the EXE file.

FIGURE 2. INFORMATION ABOUT THE MALWARE

More information about the sample used in this report appears in this table:

TECHNICAL DETAILS

Maze is a complex piece of malware that uses some tricks to frustrate analysis right from the beginning.

The malware starts preparing some functions that appear to save memory addresses in global variables to use later in dynamic calls though it does not actually use these functions later. Whether it is residual code existing in the entry point of the malware or a trick to mislead researchers is up for debate.

FIGURE 3. SAVE ADDRESS OF FUNCTIONS TO USE LATER IN A DYNAMIC WAY

Later, the malware enters in a big block of trash code that also includes some elements to decrypt strings and important information for later. The malware uses some tricks to detect debuggers at this point.

The most important of those are:

  • A big use of the PEB field “IsDebuggerPresent”. This field is a Boolean field that is filled from Windows with 1 (True) if the application is running inside of a debugger or 0 (False) if it is not.

FIGURE 4. HIGH USE OF THE “ISDEBUGGERPRESENT” PEB FIELD TO DETERMINE IF THE APPLICATION IS RUNNING IN A DEBUGGER

If the malware detects a debugger it will remain in an infinite loop without making anything while wasting system resources.

FIGURE 5. MAZE CATCHES THE DEBUGGER AND REMAINS RUNNING, WASTING RESOURCES

The malware gets all processes in the system but ignores the first one (the ‘idle process’ in Windows which is simply a tool to let the user know what percentage of system resources are being used). Using the name of each process it makes a custom name with a custom algorithm, along with a hash that is checked against a hardcoded list. If the hash is found in this list the process will be terminated.

FIGURE 6. CHECK OF HASHES FROM CUSTOM NAME OF THE PROCESSES OF THE SYSTEM

For example, the process of the debugger “x32dbg”, is caught at this point:

FIGURE 7. X32DBG PROCESS CAUGHT BY THE MALWARE WITH THE HASH

It can terminate IDA debugger, x32dbg, OllyDbg and more processes to avoid dynamic analysis, close databases, office programs and security tools.

A partial list of the processes that can be cracked using a dictionary list terminated by the malware is shown below:

dumpcap.exe -> 0x5fb805c5
excel.exe -> 0x48780528
fiddler.exe -> 0x5e0c05b1
msaccess.exe -> 0x6a9c05ff
mysqld-nt.exe -> 0x79ec0661
outlook.exe -> 0x615605dc
pipanel.exe -> 0x5fb805c4
procexp64.exe -> 0x78020640
procexp.exe -> 0x606805d4
procmon64.exe -> 0x776e0635
procmon.exe -> 0x600005c9
python.exe -> 0x55ee0597
taskkill.exe -> 0x6c2e0614
visio.exe -> 0x49780539
winword.exe -> 0x60d805d5
x32dbg.exe -> 0x5062053b
x64dbg.exe -> 0x50dc0542

This short list shows the name of the process to kill and the custom hash from the special name generated from the original process name.

FIGURE 8. TERMINATEPROCESS FUNCTION TAKEN FROM THE EXPORT ADDRESS TABLE (EAT) OF KERNEL32 AND PASSING THE HASH NAME CHECK

The malware will kill the process with the function “TerminateProcess” that it gets from the EAT (Export Address Table) of the module “kernel32.dll” to increase obfuscation, comparing the name with a custom hash taken from the name in high caps.

FIGURE 9. CALL TO TERMINATEPROCESS IN A DYNAMIC WAY TO OBFUSCATE THIS CALL

The malware calls Windows functions in a unique way to aid obfuscation, i.e. getting the first process in the system to use the function “Process32FirstW”. However, instead of calling it directly, it puts the parameters needed for the function on the stack, followed by a memory address with a “push” opcode and then makes a direct jump to the Windows function. When the function ends, Windows makes a “ret” opcode then gets the last memory address that the malware pushed inside the stack, returning to this address and continuing the flow. An example of this can be seen in this image:

FIGURE 10. HIGH OBFUSCATION TO TRY TO SLOW ANALYSIS AND MAKE IT MORE DIFFICULT

Another ploy utilized by the malware (depending of the sample) is to get the function “DbgUIRemoteBreakin”, using the function “GetProcAddress”, before employing a trick to avoid having a debugger attach to it in runtime[7].

FIGURE 11. GET DBGUIREMOTEBREAKIN USING GETPROCADDRESS TO AVOID HAVING A DEBUGGER ATTACK IT

The trick used here is “VirtualProtect” to give the function memory address of “DbgUIRemoteBreakin” permission to write to it:

FIGURE 12. GIVE WRITE PERMISSIONS IN MEMORY

After gaining permission, which is granted only for 1 byte, the malware patches this byte with a 0xC3 value (the opcode of “ret”) and restores the previous permissions with “VirtualProtect”, again in the same address and byte, removing the write permission.

FIGURE 13. PATCH THE FUNCTION WITH A RET OPCODE AND RESTORE MEMORY PERMISSIONS

This is done to avoid having a debugger attach to it in runtime. This way, when a debugger attaches to the process internally, the system calls this function but, instead of creating a thread to start the debugging, the “ret” opcode forces the function to return without creating it. In brief, it prevents a debugger from being attached correctly. It is done before enumerating the system process.

The malware checks the language of the machine with function “GetUserDefaultUILanguage” and saves the value in the stack; it is not checked automatically after the call, but it is important later.

Maze creates a mutex with the name “Global\x” where x is a special value that is unique per machine. For example, in the next screenshot (some information has been deleted to anonymize the machine used for the analysis) is an example of this behavior. It is done to avoid two or more executions at the same time.

FIGURE 14. CREATION OF A MUTEX TO AVOID DOUBLE EXECUTION. UNIQUE PER MACHINE

The malware, after creating the mutex, makes calls to the function “GetLastError” to check against two errors:

  • 0x05 -> ERROR_ACCESS_DENIED. If the malware gets this error, it means that the mutex already exists in the system but, for some reason, the malware cannot access it (perhaps privileges, policies, etcetera).
  • 0xb7 -> ERROR_ALREADY_EXISTS. If the malware gets this error, it means that the mutex already exists in the system and can be accessed.

If either of the above occur, the malware remains in execution but does not crypt any files in the system or use any resources of the machine. It means that it will appear in the program list using 0% of the processor.

The mutex value changes either per sample or on a periodic basis to avoid the possibility of vaccines being made against it. The malware also has a command to avoid the ‘problem’ of vaccines which will be explained later.

After the mutex, the malware checks the language previously saved in the stack against, for example, language 0x419 (Russian from the Russian Federation, ru-RU[8]).

The checks are done in an obfuscated way within the jumble of the code that the malware has (in the virtual machine used here the Spanish language of Spain (es-ES) was used; it is the code 0xC0A that appears in the stack in the screenshot):

FIGURE 15. CHECKING THE LANGUAGE AGAINST THE RUSSIAN LANGUAGE FROM THE RUSSIAN FEDERATION

If the language matches any of those in the list below, the malware will clean the memory and exit the main thread without wasting any resources or making any files.

  • 0x419 -> ru-RU (Russian from Russian Federation)
  • 0x422 -> uk-UA (Ukranian from Ukraine)
  • 0x423 -> be-BY (Belarusian from Belarus)
  • 0x428 -> tg-Cyrl-TJ (Tajik (Cyrilic from Tajikistan)
  • 0x42B -> hy-AM (Armenian from Armenia)
  • 0x42C -> az-Latn-AZ (Azerbaijani (Latin from Azerbaijan))
  • 0x437 -> ka-GE (Georgian from Georgia)
  • 0x43F -> kk-KZ (Kazakh from Kazakhastan)
  • 0x440 -> ky-KG (Kyrgyz from Kyrgyzstan)
  • 0x442 -> tk-TM (Turkmen from Turkmenistan)
  • 0x443 -> uz-Latn-UZ (Uzbek (Latin from Uzbekistan))
  • 0x444 -> tt-RU (Tatar from Russia Federation)
  • 0x818 -> ro-MD (Romanian from Moldova, NOT Romanian from Romania!)
  • 0x819 -> ru-MD (Russian from Moldova)
  • 0x82C -> az-Cyrl-AZ (Azerbaijani (Cyrilic from Azerbaijan))
  • 0x843 -> uz-Cyrl-UZ (Uzbek (Cyrilic from Uzbekistan))
  • 0x7C1A -> sr (Serbian)
  • 0x6C1A -> sr-Cyrl (Serbian in Cyrilic)
  • 0x1C1A -> sr-Cyrl-BA (Serbian (Cyrilic from Bosnia and Herzegovina))
  • 0x281A -> sr-Cyrl-RS (Serbian (Cyrilic from Serbia))
  • 0x81A -> sr-Latn-CS (Serbian (Latin)) (this language code starts from Windows Vista)

The malware tries to delete the shadow volumes in the system using the “wmic.exe” program with the switches “shadowcopy” and “delete”. Prior to this, the malware gets the function of “WoW64DisableWow64FsRedirection” with “GetProcAddress” and uses it to avoid redirection by default in 64-bit operating systems and calls it in a dynamic way.

The malware tries to delete the shadow copies two times, once before crypting the files in the infected system and secondly after crypting them.

This execution is done with the function “CreateProcessW” but, to increase the level of obfuscation, the malware is launched with this command:

FIGURE 16. DELETION OF SHADOW COPIES IN THE INFECTED SYSTEM WITH THE WMIC COMMAND

As you can see in the image above, the malware uses a command with the name of folders that do not exist by default in Windows, except “Windows”, “system32” and “wbem”. It enters these folders but then promptly exits them using the command “..”, meaning it returns to the previous folder in the path.

For example, in the beginning it enters the folders “ydw” and “fdygg” but later returns to the root of the Windows installation unit with two “..” commands that lead to “C:\” in this case. It later concatenates with the “Windows” folder and continues with the same behavior to finally enter into “system32” where it calls the “wmic.exe” program with the switches to delete the shadow volumes. This is done to try obfuscating this call, though such suspicious behavior may cause an antivirus program to stop it anyway, but it is proof that the malware coders have skills in programming and a good understanding of Windows behavior.

It is important to understand that this “path” used in the command with non-existent folders is random and does not need to use the same number of folders to make the obfuscation.

After the deletion process, the malware gets the function “Wow64RevertWow64FsRedirection” using the function “GetProcAddress” and calls it in a dynamic way to leave the system in the same state as before.

FIGURE 17. RECOVER THE FS REDIRECTION IN 64-BIT OPERATING SYSTEMS

Maze affects network resources too, using the functions “WNetOpenEnumW”, “WNetEnumResourceW”, “WNetCloseEnum” and “WNetAddConnection2W”.

FIGURE 18. ENUMERATING THE NETWORK RESOURCES OF THE DISK TO CRYPT FILES INSIDE OF THEM

The malware uses two algorithms to crypt the files, ChaCha which is based on the Salsa20 algorithm that is symmetric and, for protection, an RSA algorithm that is asymmetric

In each execution the malware creates a Public BLOB of one RSA key that will be used to crypt the part that holds the information to decrypt the files, and one Private BLOB with an RSA key that allows decryption of the information crypted with the public RSA blob created previously.

FIGURE 19. EXPORT OF THE RSA PUBLIC KEY BLOB GENERATED IN RUNTIME

FIGURE 20. EXPORT OF THE RSA PRIVATE KEY BLOB GENERATED IN RUNTIME

Just like other ransomware, this malware has an RSA Public BLOB embedded that will be imported to protect the RSA private BLOB of the victim. Only the malware developers have the RSA private blob to decrypt their public RSA Blob.

FIGURE 21. IMPORT OF THE RSA PUBLIC BLOB FOR THE MALWARE DEVELOPERS

This key is protected with a crypto using a key of 32 bits and iv of 8 bytes using the function “CryptGenRandom” to avoid memory dumps but, later, it will need to be decrypted before use.

After this, the malware starts the procedure of crypting the files, searching in units, before importing the RSA public BLOB key generated in runtime. After this, it creates the ransom note prepared for this infected machine in the root folder and then starts looking for folders and files to crypt.

FIGURE 22. CREATION OF RANSOM NOTE IN ROOT FOLDER AND LOOKING FOR FOLDERS AND FILES

An example ransom note, with some data anonymized, is shown below:

FIGURE 23. EXAMPLE OF A MAZE RANSOM NOTE

The procedure to crypt the files is easy, with the malware taking the following steps:

  • Check the existence of the file with the function “SetFileAttributesW” with the attribute “FILE_ATTRIBUTE_ARCHIVE”.
  • Reserve memory to the file with a call to “Virtual Alloc” for the key and iv.
  • Open the file with read and write permissions with the function “CreateFileW” with the flag “OPEN_EXISTING”.
  • Get the file size with the function “GetFileSizeEx” (it is important for managing big files, “GetFileSize” is not good for bigger files).
  • Create a file mapping with the functions “CreateFileMappingW” and “MapViewOfFile”
  • Generate a random key of 32 bytes with the function “CryptGenRandom”.
  • Generate a random iv of 8 bytes with the function “CryptGenRandom”.
  • Reserve 264 bytes of memory with the function “VirtualAlloc”.
  • Generate a new random extension for the victim file. Each file has a different extension but does not lose the original extension; the new one is appended to the old one. For example, “1.zip” becomes “1.zip.gthf”.
  • Crypt the file with the ChaCha algorithm and the key and iv with the RSA public key generated in runtime.
  • Write this new block with the key and iv to decrypt at the end of the file.
  • Rename the file with the function “MoveFileExW”. That way it is not possible to use forensic tools to recover the files because they use the same sector on the raw disk. The malware does not delete the file using the function “DeleteFileW” and later create a new one with the crypted data. Instead, all changes are applied in the mapping directly, in memory, without using a file pointer on the disk to read and write, which makes the process much quicker.
  • The image of the file is unmapped, and handles closed.
  • The process is repeated with new files.

The list of folders that the malware avoids are:

  • Windows main directory.
  • Games
  • Tor Browser
  • ProgramData
  • cache2\entries
  • Low\Content.IE5
  • User Data\Default\Cache
  • All Users
  • Local Settings
  • AppData\Local
  • Program Files

The malware ignores these file extensions:

  • LNK
  • EXE
  • SYS
  • DLL

The malware also has a list of filenames that will not be crypted:

  • inf
  • ini
  • ini
  • dat
  • db
  • bak
  • dat.log
  • db
  • bin
  • DECRYPT-FILES.txt

However, it does crypt the file “ntuser.ini” to prevent other ransomwares from crypting it. It creates the ransom note in each folder that it can.

When the malware finishes crypting all files it changes the desktop wallpaper to this image:

FIGURE 24. THE MALWARE CHANGES THE DESKTOP WALLPAPER AFTER CRYPTING THE FILES

The malware tries to make connections to IP addresses that have been crypted in the binary to send information about the infected machine, as seen below:

 

hxxp://91.218.114.4/nwjknpeevx.action?pw=g1y652l&kyn=21y3vvhh&dvr=5e&us=g25e3582a

hxxp://91.218.114.11/forum/siaib.jspx?v=h&xyna=0vip863&eul=xsn3q0

hxxp://91.218.114.26/view/ticket/pigut.jspx?o=664quo0s&fp=ot52

hxxp://91.218.114.25/xrr.jspx?ygad=r35e2cx&e=6as6ta

hxxp://91.218.114.4/j.php

hxxp://91.218.114.11/payout/view/fa.aspx?y=y&qbx=4&kws=n2&iuy=8k7

hxxp://91.218.114.25/lxh.asp?mtxm=l7&r=836wy5

hxxp://91.218.114.26/signin/ticket/eq.action?x=yk6rr&e=50b&q=327dr5&ofk=065cdp

hxxp://91.218.114.31/signin/rnmnnekca.jsp?kdn=6snl5&e=7a50cx4hyp

hxxp://91.218.114.31/forum/a.aspx?byx=56&bc=62t0h&u=75w6n6&sot=2v0l761or6

hxxp://91.218.114.32/withdrawal/checkout/l.do?nuny=qj6&sdv=45g2boyf5q&dnr=rh8lk31ed

hxxp://91.218.114.77/task/bxfbpx.jspx?nq=cge63

hxxp://91.218.114.38/account/payout/ujwkjhoui.shtml

hxxp://91.218.114.37/imrhhjitop.phtml?wto=344dsc84&sp=x&oml=c173s71u&iy=m3u2

hxxp://91.218.114.38/auth/login

hxxp://91.218.114.79/logout/hfwdmugdi.php?upaj=mj7g

hxxp://91.218.114.38/sepa/juel.php?ars=51qse4p3y&xjaq=r5o4t4dp

hxxp://91.218.114.32/fwno.cgi?yd=410&o=y7x5kx371&p=m3361672

hxxp://91.218.114.37/sepa/signout/mjsnm.aspx?r=7o47wri&rtew=uu8764ssy&bri=51gxx6k5&opms=72gy0a

hxxp://91.218.114.77/payout/analytics/lrkaaosp.do?y=62h&aq=3jq8k6&v=0svt

hxxp://91.218.114.79/create/dpcwk.php?u=28qy0dpmt&qwbh=k&f=g1ub5ei&ek=3ee

 

It is important to take into consideration that the malware forges the POST string to make the connection with a random choice from a list of possible strings such as “forum”, “php”, “view”, etc., to make detection harder with IPS or other filters on the network.

The IP addresses are detected as from the Russian Federation but that does not prove that the malware came from this country; it could be deliberate misdirection but, with the language checks of CIS countries, it certainly appears possible.

The use of IP addresses instead of domain names is to avoid DNS resolutions that can be altered or redirected to a loopback, for example using the “host” file in Windows. This makes the trace of IPs more complicated and avoids having the connection blocked.

The malware uses this agent to make the connection, but it can change between samples:

FIGURE 25. AGENT USED TO MAKE CONNECTIONS TO THE C2C IP ADDRESSES

From a memory dump we can extract the IPs used by these connections, as well as a curious string that talks about Lawrence Abrams, the admin of the web site “bleepingcomputer” who was contacted directly by the developers. It is not known why they included this email address because it has no relation to the ransom note and is not used anywhere else. Perhaps it is a means of mocking the administrator of a site that frequently reports on ransomware?

FIGURE 26. C2C IP ADDRESSES EXTRACTED FROM THE MEMORY

The connections to the C2C IP addresses, in a pcap using Wireshark, can be seen perfectly:

FIGURE 27. CONNECTION IN PCAP WITH THE C2C IP ADDRESSES

Maze has some strings in memory that are interesting and something that may be worth further analysis in the future:

FIGURE 28. CURIOUS STRING FOR FUTURE INVESTIGATION

The webpage for making the payment requested in the ransom note gives a price and verifies that all is correct.

FIGURE 29. MAZE PAYMENT WEBPAGE AFTER DECRYPTING THE RANSOM NOTE

Maze has a chat function to contact the operators and receive information about how to obtain the cryptocurrency required to make payment.

Of course, as with many types of ransomware, there is an offer to decrypt three images for free and that service has been verified as working:

FIGURE 30. FREE DECRYPTION WORKS SO THE MALWARE SAMPLE IS CORRECT

SWITCHES

The malware has some switches that can be used in the command line to launch. These switches can either disable some elements or enable logging.

The switches are:

  • –nomutex -> This switch prevents checking the mutex so that it can run more than one instance on the same machine. It can also be used to avoid vaccines that are made before the malware creates the mutex name in the machine.
  • –noshares -> With this switch the malware will not crypt network shares, only the local machine.
  • –path x -> Where x is a full path. In this case the malware will crypt all files in all folders starting from this path unless they are blacklisted names, extensions or folder names. This is useful for the malware developers to attack a special path instead of losing time going after a full machine and it makes the attack more targeted.
  • –logging -> If this switch is enabled the malware will log all the steps it makes. Useful to the malware developers in debug environments, or in the attack phase to know that all was ok, step by step. Here is a small example of this information:

FIGURE 31. EXAMPLE OF THE INFORMATION THAT THE MALWARE CAN GIVE WITH THE LOG SWITCH

OTHER SAMPLES

In January 2020 a new version of the malware appeared with a special text dedicated to some researchers in the security field. The malware developers appear to have chosen those individuals to be provocative and make fun of them.

The sample was discovered by malwrhunterteam[9] on the 28th of January 2020. The sample has some differences when compared with the previous one that was analyzed in this report. Those differences will be covered later via another sample that was found by Luca Nagy[10] on the 30th of January 2020.

The most important thing here is that the developers appear to have carefully selected the researchers and waited for them to answer as a psychological trick, and it worked, because all of them replied, trolling the malware developers over the version of their malware detected on the 28th.

Here is one response from a malware developer to this trolling that contains some interesting facts:

FIGURE 32. RESPONSE FROM A MALWARE DEVELOPER

  • It is not known if one person is behind the malware or not. It is curious that they said “I” instead of “we” twice in their answer. So, perhaps it was written by one person for trolling purposes, or perhaps the developer of the malware really is only one person (or they want researchers to think that is the case).
  • Another important fact in the note is the talk about the tools used by one of the researchers for regular malware analysis. Why are they mentioning regular malware analysis? Is it because they are reversing malware themselves for fun or could it be their day job? Could it be that perhaps the developer is a researcher (because of the way that they talk with others and provoke them)? Secondly, malware analysis is mentioned more than once and, thirdly, they said that they made an IDAPython script to remove all obfuscated code that the malware has (the ransomware may have got the name ‘Maze’ because of how analysis of it is like walking through a labyrinth). So, it may be either a researcher who knows IDAPro very well or is an advanced developer (and the obfuscated code in Maze is very well done) or perhaps it is a developer that has another job in normal life besides the creation of malware? Of course, these are just possibilities, not facts.
  • The malware developer achieved their goal with this interaction as their target audience saw the answer and talked about their malware, as noted in the final line of their response “ …but you need to know that we love you researchers without you our job also would be fuc**** boring as hell”.

It is curious that here they said “we” instead of “I” as before but perhaps they were talking about all malware development?

The differences that these samples have are:

  • Usually comes as a DLL instead of an EXE file. It does not run on Windows operating systems older than Vista as this makes analysis harder. By using the malware as a DLL, they can inject this module into a target process more easily than if they use an EXE sample of the malware.
  • Instead of deleting the “Shadow Volumes” the developers instead use WMIC with the special trick of the path as mentioned earlier, using WMIC classes to control the Shadow Volumes. An example of this use can be seen in the next image.

FIGURE 33. USING WMIC CLASSES IF NEEDED TO GET THE SHADOW VOLUMES

Each sample of the malware uses different strings as PDB to send messages or to make the sample unique, for example:

  • C:\somerandomsh**\sh**\obama.pdb
  • C:\kill\yourself\<nickname>\chinese\idio*.pdb

(In these examples some things were removed or changed to remove sensitive information in the report).

The new samples discovered in January 2020 make these connections to the C2 (or try to make them):

FIGURE 34. CONNECTIONS TO C2 IP OF THE NEW SAMPLES

As we can see, they are the same IPs as seen in the previous versions of the malware.

The samples’ compile dates are from the 24th of January 2020 (the first version with the strings that provoked the researchers) to the 28th of January 2020 (the version with the answers to the researchers), meaning they were made on the same day the responses to the previous version were published on Twitter.

Another interesting fact from the later sample is that, besides it saying that the language code used to program it was Korean, the IPs where it connects belong to the Russian Federation as before, as can be seen in the next two images.

FIGURE 35. LANGUAGE CODE “USED” IN THE PACKER SAMPLE, NOT THE MALWARE

FIGURE 36. ALL C2 DOMAINS BELONG TO THE RUSSIAN FEDERATION

It is impossible to know the truth, but this could be a trick to try misleading researchers into thinking that the malware comes from some country when in truth it originates in another. It is known that malware developers often check the language on potential victim’s machines to avoid the CIS countries, so we can guess that the check for the “Korean” language was a trick designed to mislead, but it is impossible to know that for sure. Of course, the “Korean” language can be changed manually, or it could be a Korean packer, but it is impossible to say with certainty.

CONCLUSION

Maze is a ransomware created by skilled developers. It uses a lot of tricks to make analysis very complex by disabling disassemblers and using pseudocode plugins.

It poses a big problem to individuals and enterprises that do not pay as the developers threaten to release the information if they do not receive payment and they do indeed keep their word on that. More and more ransomwares are exhibiting the same behavior and we expect to see more of it this year and perhaps further into the future too.

The malware developers are active on social media sites, such as Twitter, and they are familiar with the work of malware researchers. They also know how to provoke them perfectly and they like to play cat and the mouse with them.

We recommend making periodic backups of files and keeping them isolated off the network and having an always updated antivirus in place. The latest software patch should also be applied. Remote Desktop Connections that are not needed should be avoided.

Avoid suspicious emails and do not open attachments that come from anyone that you do not know. The same goes for links in emails and, even if they come from a known source, check with the sender if you have any doubts. Also, disable macros in Office programs and never enable them unless it is essential to do so.

COVERAGE

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

The names that it can have are:

  • Ransom-Maze!<hash>

YARA RULE

rule maze_unpacked {

   meta:

      description = “Rule to detect unpacked Maze samples”

      author = “Marc Rivero | McAfee ATR Team”

    

   strings:

      $opcode_sequence = { 5589e583ec208b450c8b4d08c745fc00 }

 

                  $opcode_sequence_2 = { 5589e553575683e4f883ec28c7042400 }

 

                  $opcode_sequence_3 = { 5589e55dc3662e0f1f84000000000090 }

 

                  $opcode_sequence_4 = { 5589e553575683e4f081ec600200008b }

 

                  $opcode_sequence_5 = { 5589e553575683e4f081ecc00000000f }

 

                  $opcode_sequence_6 = { 5589e583ec208b45108b4d0c8b550883 }

 

                  $opcode_sequence_7 = { 5589e5575683ec388b45108b4d0c8b55 }

 

                  $opcode_sequence_8 = { 5589e5575683e4f883ec088b45088b48 }

 

                  $opcode_sequence_9 = { 558b6c241468997a41000f84bdc50000 }

 

                  $opcode_sequence_10 = { 5589e553575683e4f883ec588b5d088b }

 

                  $opcode_sequence_11 = { 5589e553575683e4f083ec408a42048b }

 

                  $opcode_sequence_12 = { 5589e583ec188b4508837d08008945fc }

 

                  $opcode_sequence_13 = { 5589e553575683e4f8b8d05b0000687f }

 

                  $opcode_sequence_14 = { 5589e5508b450831c98945fc89c883c4 }

 

                  $opcode_sequence_15 = { 5589e553575683e4f883ec708b5d0889 }

                 

                  $opcode_sequence_16 = { 5589e583ec308b45088b4d08894df883 }

 

                  $opcode_sequence_17 = { 5589e553575683e4f881ec18030000f2 }

 

                  $opcode_sequence_18 = { 5589e583ec188b45088b4d08894df48b }

 

                  $opcode_sequence_19 = { 5589e583ec2056be74c14400566a0068 }

 

                  $opcode_sequence_20 = { 5589e553575683e4f081ec900000008b }

 

                  $opcode_sequence_21 = { 5589e583e4f083ec208b4d108b450c0f }

 

                  $opcode_sequence_22 = { 5589e55383e4f883ec108b4d0c8b4508 }

 

                  $opcode_sequence_23 = { 558b8e150409133f03fd08f81b0c4f22 }

 

                  $opcode_sequence_24 = { 5589e553575683e4f883ec7031f68379 }

 

                  $opcode_sequence_25 = { 5589e553575683e4f881ec3001000089 }

 

                  $opcode_sequence_26 = { 5589e553575683e4f881ece00000000f }

 

                  $opcode_sequence_27 = { 558b589608361d1943a57d0ba6492beb }

 

                  $opcode_sequence_28 = { 5589e553575683e4f883ec1089ce6a00 }

 

                  $opcode_sequence_29 = { 5589e5575683e4f883ec688b75088b7d }

 

                  $opcode_sequence_30 = { 5589e553575683e4f883ec386a006a00 }

 

                  $opcode_sequence_31 = { 558b7c240868dca8440057683d484300 }

 

                  $opcode_sequence_32 = { 5589e55683e4f881ec2801000089ce8d }

 

                  $opcode_sequence_33 = { 5589e583ec188b450831c98b5508c704 }

 

                  $opcode_sequence_34 = { 5589e583ec308b450c8b4d088b55088b }

 

                  $opcode_sequence_35 = { 5589e583ec348b450831c983c1188b55 }

 

                  $opcode_sequence_36 = { 5589e553575683e4f881ec78040000f2 }

 

                  $opcode_sequence_37 = { 5589e583ec108b4508837d08008945f8 }

 

                  $opcode_sequence_38 = { 5589e583ec348b4508837d08008945dc }

 

                  $opcode_sequence_39 = { 5589e55683ec548b45088b4d08894df0 }

 

                  $opcode_sequence_40 = { 558bec5de9a48efeffe9ef8efeffcccc }

 

                  $opcode_sequence_41 = { 5589e553575683ec108b45108b4d0c8b }

 

                  $opcode_sequence_42 = { 5589e5575683ec348b4508c745f40100 }

 

                  $opcode_sequence_43 = { 558bec8325a0c345000083ec1c5333db }

 

                  $opcode_sequence_44 = { 5589e553575683e4f083ec208b750c0f }

 

                  $opcode_sequence_45 = { 5589e583ec348b450c8b4d088b55088b }

 

                  $opcode_sequence_46 = { 558b6fd8d843ef516154e2526781aecd }

 

   condition:

 

      ( uint16(0) == 0x5a4d) and 38 of them

}

IOCs

Network

Domain          mazedecrypt.top

IP                     91.218.114.11

IP                     91.218.114.25

IP                     91.218.114.26

IP                     91.218.114.31

IP                     91.218.114.32

IP                     91.218.114.37

IP                     91.218.114.38

IP                     91.218.114.4

IP                     91.218.114.77

IP                     91.218.114.79

MITRE ATT&CK COVERAGE

  • CommonlyUsedPort
  • StandardApplicationLayerProtocol
  • SecuritySoftwareDiscovery
  • SystemTimeDiscovery
  • CommandLineInterface
  • DataEncrypted
  • DataEncryptedForImpact
  • Query registry
  • Hooking

[1] https://twitter.com/jeromesegura/status/1133767240686288896

[2] https://www.bleepingcomputer.com/news/security/maze-ransomware-demands-6-million-ransom-from-southwire/

[3] https://www.bleepingcomputer.com/news/security/nemty-ransomware-to-start-leaking-non-paying-victims-data/

[4] https://twitter.com/McAfee_Labs/status/1206651980086685696

[5] https://www.bleepingcomputer.com/news/security/new-threat-actor-impersonates-govt-agencies-to-deliver-malware/

[6] https://securityintelligence.com/news/spelevo-ek-exploits-flash-player-vulnerability-to-deliver-maze-ransomware/

[7] https://github.com/revsic/AntiDebugging

[8] https://ss64.com/locale.html

[9] https://twitter.com/malwrhunterteam/status/1222253947332841472

[10] https://twitter.com/luca_nagy_/status/1222819371644522500

The post Ransomware Maze appeared first on McAfee Blog.

SMBGhost – Analysis of CVE-2020-0796

13 March 2020 at 02:44

The Vulnerability

The latest vulnerability in SMBv3 is a “wormable” vulnerability given its potential ability to replicate or spread over network shares using the latest version of the protocol (SMB 3.1.1). As of this writing, Microsoft have just released a patch for CVE-2020-0796 on the morning of March 12th. The bug was introduced very recently, in the decompression routines for SMBv3 data payloads. The code implementing this was deployed in April 2019 for Version 1903 and November 2019 for version 1909.

The vulnerability occurs during the processing of a malformed compressed message. The header of the message follows this format: (from [MS-SMB2])

  • There are two parameters in the header that are of interest: OriginalCompressedSegmentSize and Offset/Length
  • The Srv2DecompressData (srv2.sys) function allocates a buffer of size OriginalCompressedSegmentSize + Offset/Length
  • This is not checking the signedness of these values, and as the addition is signed an attacker can allocate a buffer smaller than intended
  • Data is being decompressed at buffer + offset, using data from packet+0x10+offset
  • OriginalCompressedSegmentSize is used as the UncompressedBufferSize parameter passed to SmbCompressionDecompression which is a wrapper for RtlDecompressBufferEx2
  • This routine assumes the uncompressed buffer size to be an unsigned long so a negative value gets cast into a large unsigned number
  • Because of this, the decompression routine decompresses the buffer and can go well beyond the original size, as it is assuming it has a very large buffer to work with

Here’s an annotated disassembly of the relevant function on the server side:

This flaw can affect both client and server in SMB negotiations in a compressed message sent after the Negotiate Protocol Responses. The server vulnerability is within srv2.sys and the client vulnerability is within mrxsmb.sys which both end up calling the same code in SmbCompressDecompress.

Here’s an annotated disassembly of the relevant function on the client side – unlike the server side the OriginalCompressedSegmentSize is bounds checked but there is no check on offset/length before they are combined and passed to ExAllocatePoolWithtag. We have confirmed the BSOD crash from both client->server AND server-client using this vulnerability.

If a computer allows inbound SMB3 traffic over port 445, by default compression is supported and the client and server will negotiate the “terms” of this compression and then the client will proceed to transfer a compressed payload.

The flaw is present in the SMB Compression Transform Header, prior to any kind of authentication.

We can see the very large OriginalSize used for attacker-controlled data (4294967295 is 0xFFFFFFFF in hex which is also -1 if viewed as a signed long). This is copied into a smaller fixed buffer and results in a classic buffer overflow. Of note is the ProtocolID of \xfcSMB, which must be present and represents the magic bytes used to indicate the message must be decompressed per the spec.

However, it is not just the server-side which is vulnerable to this attack. If a client connects to a malicious SMB server, both sides run the same vulnerable code and a malicious server can respond to client requests in the same way to trigger the overflow on the initiator/client side. In this scenario, the Windows Powershell command referenced here will not be effective in stopping this attack against the SMB client. It will only be useful when implemented on the SMB server/recipient side pre-authentication.

Exposure

As always, this kind of patch should be applied as soon as possible, subject to organizational policy. While there are currently no known exploits in the wild, as you will see, causing a BSOD (blue screen of death), is quite trivial, and remains a highly effective attack method for disruption if an attacker can gain access to an internal network.

More dangerous yet are any systems exposing port 445 to the Internet, as we have seen the damage possible through similar bugs such as WannaCry. As of the time of this writing and just prior to Microsoft releasing its patch, Shodan.io appears to have just over 35,000 Windows computers reporting the vulnerable versions of software as searched by: port:445 os: “Windows” + os: “18362” for example. Many of these will likely be patched quickly now that a fix is out.

Patch Analysis

Looking at the patched version, we can see the code is now using RtlULongAdd to add  OriginalCompressedSegmentSize and the Offset/Length value. There also seem to be an extra test to make sure the size is not bigger than the whole packet plus 0x134.

Looking a little further, we can also see the usage of RtULongSub for computing the size of the compressed buffer while accounting for the offset field.

Finally, we can also notice the usage of WPP tracing code in case an error occurs (tracing was already occurring throughout the driver, but this specific function was not previously instrumented in such a way).

Impact – BSOD vs. RCE

Getting a Blue Screen of Death or BSOD is a straightforward exercise. Pivoting from that to full remote code execution will likely be more challenging, as additional bugs will likely be required to bypass Windows’ latest mitigation techniques, such as Kernel ASLR or KASLR. For this bug, the attacker will have easy primitives for the allocation of data and can control the size of the data used to trigger the overflow. On the flip side, the objects allocated in memory to store the attacker input are freed relatively quickly, making exploitation more difficult.

Product Detection/Mitigation

McAfee has released NSP ID 0x43c0e600 – NETBIOS-SS: Samba Remote Code Execution Vulnerability (CVE-2020-0796) to address exploitation of the vulnerability. We are working on developing additional signatures to complement or replace this coverage.

 

The post SMBGhost – Analysis of CVE-2020-0796 appeared first on McAfee Blog.

Multi-tricks HiddenAds Malware

4 March 2020 at 05:01

Thousands of HiddenAds Trojan Apps Masquerade as Google Play Apps

The McAfee mobile research team has recently discovered a new variant of the HiddenAds Trojan. HiddenAds Trojan is an adware app used to display advertising and collect user data for marketing. The goal of such apps is to generate revenue by redirecting users to advertisements. There are usually two way to make money with adware; the display of advertising to a user’s computer and a per-click payment made if a user clicks on the ad.

Although it can be used for spreading and displaying advertising in an affiliate marketing program, adware can also be used to spread malware in an affiliate fraud program. Most adware programs will abuse a legitimate application to trick the user and increase the number of installations. In our analysis we focus on two fake versions of popular Android apps:

  • FaceApp: an app used to modify photos with machine learning.
  • Call of Duty: a famous game adapted for Android.

We notice that these applications are very popular and are usually downloaded by young people. Additionally, both apps are using the in app-purchase business model. These two elements are interesting because they increase the chance that people will search for free versions and have potentially low concerns regarding security. We also noticed several other HiddenAds variants masquerading as genuine apps, such as Spotify or other well-known games.

Globally, we observed more than 30,000 samples related to this HiddenAds campaign.

https://www.virustotal.com/graph/g05e894f94d9b40ab9651e0b353a66b8b4eb54e6dc8884fc2b52b86e205bc8fcc

Figure 1. Multi-tricks HiddenAds campaign

Analyzed samples are not available on the Google Play Store; the delivery of the latest variants is mostly from untrusted parts of the internet that propose APK file downloads. YouTube channels have also been spotted with malicious links to download the fake apps.

These variants of HiddenAds use some other interesting technologies to trick users and thwart the analysis of malware researchers. In this blogpost, we will deep dive into the analysis of a fake FaceApp application.

Distribution Channel

These malware samples masquerade as popular applications so, when a user wants to find the apps from an unknown source, they could be infected by malware. For example, “Call of Duty” is a popular game, with many people searching for the mobile version online. If they are unfortunate, they may find the result shown below:

Figure 2. Distribution channel

In the video, the author provides download links. If we click the link to download the file, we receive “Call of Duty_1.0.4.apk” (as seen in Table 1). If we install this sample on our devices, we will be infected by this malware. Additionally, we spotted this malware on other untrusted sources.

Trick Techniques

  1. Application name trick.

As a user, we recognize an app by its name and icon. As a researcher, the package name is an identification of an application. This variant uses popular application names, icons and package names on the Google Play store, to trick users into thinking they are genuine applications.

Table 1: Basic Information of some threat samples.

We search for the application name on Google Play and click the search result to view its details.

Figure 3. FaceApp information on Google Play.

This is a very popular application with in-app purchases. If victims want to find a free cracked version from alternative sources, they may end up with our analysis sample. The application name, icon and version number of the Google Play app and the fake app are very similar. The file size, however, is very different so we should keep that very firmly in mind.

  1. Icon trick.

Normally, users expect the icons seen before and after installation to be the same. In this sample, they are different. The sample defines two icons in the AndroidManifest.xml file; the label of activity is “Settings”.

Figure 4.1. Two icons are defined in AndroidManifest.xml

Before we install the sample, we see it in File Explorer, showing the first icon (tv_icon.png). At the system installation view, we see the first icon too. Once we click the “Done” button, the sample is installed onto the device and the system shows the second icon (but_invertc.png).

                Figure 4.2. Icons before/during/after installation

This is the icon trick. Users are surprised after they install the sample as they cannot find the expected icon on their devices; they maybe think something went wrong during installation and the application failed to install. In reality, the application has already been installed; it is next to the system “Settings” application icon. When a user goes to launch the system “Settings” application, they have the possibility to click the fake icon instead, launching the malicious application.

  1. Launcher trick.

Once a victim clicks the fake “Settings” icon, the malicious app launches, as does the next stage of the trick.

Figure 5. Hidden icon after clicking “ok” button

The sample shows this alert dialog immediately; it does not perform country available checking. This is a deceptive message, to make victims believe that the icon is hidden because “Application is unavailable in your country”. In fact, the application is still running in the background. It is not unavailable in a given country, it is just unavailable for victims.

Obfuscation Technique

Above are the ways the app is used to defraud victims. Now, we look at the anti-analysis techniques of this sample. At the start of the application, it invokes a function MultiDex.install. MultiDex is a popular and valid Android module which is used to support multi DEX files. When we investigate this function, we are curious why a popular Android module invokes a function in a specific application module.

Figure 6. The malicious code in the “MultiDex.install” function

The question prompts us to do more analysis. Finally, we find that this is the malicious code entrance. It mainly does 2 things here:

  • Decrypt so library
    The decrypted function is very obfuscated, not only obfuscating the variable name such that it makes no sense, but also splitting a simple function into lots of sub-functions, each of which inserts lots of nonsense code, designed to thwart analysis.
  • Fortunately, we can understand the code and get the decryption process.

Figure 7.1. Splits into lots of sub-functions

Figure 7.2. One sub-function, lots of code is nonsense

Reading data from resource/string.xml file according to CPU type (Figure 8.2):

  • If CPU is arm64, read x1 value.
  • If CPU is armeabi, read x0 value.
  • Other CPUs are not supported.

Figure 8.1. Read data from resource string.xml file

The data has 2 parts, the first part is the header of the ELF file, the second part is an index of array.

  • From the index (“a58ax”) in the last step, we find base64 encoding data from the arrays.xml file.
  • Use base64 and XOR operation to decode the array and generate native code library.

Figure 8.2. Base64 encoding data in the file resources.arsc/res/values/arrays.xml

 3) Load so library to extract the DEX payload and, finally, the malicious code invokes system.load to load the so library and calls a native function.

Figure 9. Load so library and call a native function

In the native function, it will extract and decrypt the file assets/geocalc_lite.dat and restore the DEX payload to path /data/data/de.fastnc.android.geocalc_lite/app_app_apk/geocalc_lite.dat.jar.

DEX Payload Analysis

The DEX Payload is used for showing advertisements. The advertisement data comes from the server. Once the payload gets the data, it will show it on the device. From the code analysis, we see there are dozens of advertisement types (Figure 12.2). The payload, which is very complex, will load and show the data in different ways for each type.

  • Default Setting Parameters
    The DEX payload defines a base64 encoding string in code; we get lots of default setting parameters after decoding it:

Figure 10.1. Default setting parameters (Encoding)

        

Figure 10.2. Default setting parameters (Decoding)

This is a json object; it is very complex and below is the usage of some parameters:

  • metricsApiKey: The API Key of Yandex Metrica SDK.
  • installFrequencySeconds : This is used to control the frequency of ‘install’ request. The value decides the minimum time interval of sending ‘install’ requests (see the Request & Response section) which, in this instance, is 1000 seconds(16 minutes 40 seconds). The install request can only be triggered by the application launcher. However many times we restart the application, it only sends one request in 1000 seconds.
  • overappStartDelaySeconds : This is designed to control the delay of http requests. It is intended to execute malicious payloads after 30000 seconds (5 hours 20 minutes) from the first launch. But in the current version, this value is the same as ‘installFrequencySeconds’ and is used to control install frequency. The smaller value of ‘overappStartDelaySeconds’ and ‘installFrequencySeconds’ is used as the minimum time interval of sending install requests.
  • bundles_*(b,c,l,n): It looks like these are used for determining whether to show advertisements in these packages or not.

The parameter “domains” is an important one; it defines the remote server candidate list. Payload selects a random one as the remote server; if the selected one is unavailable, it will switch to the next one.

Request & Response

There are 3 types of requests in the payload, with different requests having different trigger conditions. We can only capture 2 types of requests:

Figure 11.1. Request & response capture

  1. ‘install’ Request
    During application launch, if the trigger conditions are satisfied, the payload will send an ‘install’ request to the remote server. This request has a file named “type” whose value is “install”.

Figure 11.2. Install request

The client filed is a json object too; it contains the versionName and sdkEdition information, both of which show that this payload is very new.

Figure 11.3  VersionName and sdkEdition definition

The responses from the remote server are often an empty json which increases the difficulty of our analysis. We continued testing for a few days and captured a non-empty response.

Figure 11.4. Response data

The remote server settings cover the default settings:

  • Enabled: Advertisement enabled flag, including below ‘b/request’ request. The default is False, and True is set from a remote server response.
    • 7 new domains in response: ‘http://hurgadont.com’, ‘http://asfintom.com’, ‘http://eklampa.com’, ‘http://glanmoran.com’, ‘http://cantomus.com’, ‘http://fumirol.com’ and ‘http://bartingor.com’
    • 7 default domains: “http://minasorp.com”,”http://omatist.com”,”http://retinba.com”,”http://baradont.com”,”http://lindostan.com”, “http://avgon.net” and “http://dorontalka.com”

There are 7 new servers and 7 default servers, a total 14 servers, and we can ping all of them; they are alive.

2. ‘b/request’ request

This is a core request. There is a field named ‘type’ and its value is ‘b/request’ in this request.

Figure 12.1   b/request request

The library registers lots of event filters/observers and, when these events happen, the trigger conditions are satisfied, causing the library to send appropriate requests to the remote server.

Table 2: Event monitoring

Banner Type is used to identify the banner and Spot is used to identify the spotting of events.

Figure 12.2. Banner Type & Spot Type

 The response data is as below. It has 3 main functionalities:

  • ‘sdkUpdate’ data: Used to load updated versions of the SDK file.
  • ‘banners’ data: Used to show banner advertisements.
  • ‘mediatorSDKs’ data: Used to post mediatorSDKs requests on victims’ devices.

Figure 12.3. ‘b/request’ Response

  • Banner data

We mentioned that we captured a response of ‘b/request’ in Figure 11.1. The response contains one banner data, the fields of banner data are as below after decoding.

Figure 12.4. Banner data and ‘html’ field content

                ‘html’ is the most important field – payload content is loaded in a WebView by invoking the loadDataWithBaseURL API. According to the html, WebView will load the page from the first URL, hxxp://bestadbid.com/afu.php?zoneid=1558701. This is a redirect URL that will redirect to different URLs each time we open it.  In our test, it redirects to a gambling website.

Figure 12.5. Redirect to a gambling website

  • mediatorSdks data: mediatorSdks data is a json array. Each item definition is as below. We cannot capture this type of data from the remote server as we do not know the real value of each field. According to our analysis, “tracking” is a URL list. Each URL will be executed on the device and the executed result sent to the remote server.

Figure 12.6. mediatorSdks item definition

3) Mediator Stat requests: After the Tracking URL executes, it will execute /sdk/stat/mediator_* requests to the remote server which just reports the execute results. There are 4 types of mediator requests, one is for reporting failure status, the other 3 types are for reporting success status. There are 3 types of success status; we guess that there are 3 types of Tracking URL in mediatorSdks data (Figure 12.6). Each type of Tracking URL uses each mediator stat request to report status.

Figure 12.7. 4 types of mediator stat request

Conclusion

This is a traditional Hidden Icon Ads malware; it hides the application’s icon first, then shows advertisements from the DEX payload. But it applies lots of technology to implement its purpose, to trick users into believing it is a normal application, to stymie the detection of security tools. The DEX payload is a very complex SDK – more than 14 candidates of remote servers are found, lots of event monitoring and remote trigger control, all of which mean this is a well-designed malware. Once victims are infected with this malware they are unlikely to realize it and, even if they do, they may not be able to locate and remove it.

McAfee Mobile Security detects this threat as Android/HiddenAds. To protect yourselves from this and similar threats, employ the McAfee Mobile Security application on your mobile devices and do not install apps from unknown sources.

For more information about McAfee Mobile Security, visit https://www.mcafeemobilesecurity.com.

Hashes

bc6f9c6d9beecd6f1353953ef6d883c51739ecec7e5b55e15319fe0d0b124a6d

7c40fabb70556d7d294957ec0fa1215a014a33f262710a793dd927100b183454

12be1c7ffdcf1b1917b71afa4b65a84b126ab0f0fbf6dc13390a32e6a8b84048

ed47a5871132c22bf4b7888908f35cacc2cd0c2a6e8e0afffea61d0e14792ea4

8c5826441a7000f957ece60a3e5294732f9a430d4bec0113bb13b99c73fba47c

04e6493d3cb0b92bebb450f37b21f9176fe266c662f65919baf7d62297

The post Multi-tricks HiddenAds Malware appeared first on McAfee Blog.

❌
❌