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.

On June 16^th, 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.

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.

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.

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.

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.

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.

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)

• Organizations Leave Backdoors Open to Cheap Remote Desktop Protocol Attacks
• RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708
• Cybercriminals Actively Exploiting RDP to Target Remote Organizations

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.

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

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

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

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
• Malware
• Ursnif
• Fareit
• COVID-19 Ransomware
• Emotet
• Azorult
• NetWalker
• Nanocore RAT
• Hancitor
• Heat Map
• Spam
• URL
• IOCs
• Recommendation
• Software Updates
• Spotting Spam/Phishing emails
• Global Threat Intelligence (GTI)
• Endpoint Security (ENS) Product
• Unified Cloud Edge
• Conclusion

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.

• Using Expert Rules in ENS to Prevent Malicious Exploits
• Endpoint Security 10.6 Threat Prevention Product Guide

 

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

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:

• https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2020-0609
• https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2020-0610

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.

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:

• Targeted Countries
• Attack Analysis
  • Initial Access
  • Network Infiltration
  • Credentials and Privileges
  • Lateral Movement
  • Ransomware Deployment
  • Malware Analysis
  • Payload Analysis
  • Technical Analysis
• Insights from the Underground
• Recovery
• Conclusion

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.

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.

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.

 

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:

• In 2019, vulnerabilities in Palo Alto Networks, Fortinet, Pulse Secure, and Citrix VPN servers were targeted
• Proof-of-concept exploits have been developed for Citrix NetScaler/Application Delivery Controller (ADC), Cisco VPN routers and the Zoho ManageEngine Desktop Central
• Fox-IT discovered bypassing of a VPN two-factor authentication
• Proof-of-Concept exploits have been developed for vulnerabilities in Telecommuter Applications such as Zoom, Confluence and Slack
• There have been vulnerabilities recently disclosed in Android and iOS free VPNs
• RDP vulnerabilities have been disclosed over the last year such as Dejablue, Bluegate and a proof-of-concept exploit in the case of Bluekeep (wormable)

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

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:

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.

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.

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.

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 12^th. 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.

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.

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

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

The McAfee Mobile Research team has identified an Android malware family dubbed Android/LeifAccess.A that has been active since May 2019. This trojan was discovered globally with localized versions but  has a much higher prevalence in the USA and Brazil. As part of the payload, this trojan can abuse OAuth leveraging accessibility services to automatically create accounts in the name of a victim’s legitimate email in multiple third-party apps. Using the same approach, it can create fake reviews on the Google Play store to manipulate app rankings, perform ad-fraud (clicker functionality), update itself and execute arbitrary remote code, among other functionalities.

Meanwhile, many targeted apps affected for fake reviews are on Google Play.

This malware has not been identified in the official Android store so some of the potential distribution methods that we identified are related to social media, gaming platforms, malvertising and the direct download of the APK files from the Command and Control (C&C) Server.

Social Engineering to get Accessibility Services

Once installed, Android/LeifAccess.A does not show any icon or shortcut. It runs in the background and may ask victims to activate accessibility services to perform most of its malicious activities by displaying a toast notification, simulating a system warning as shown below:

Accessibility services were designed to assist users with disabilities, or while they were otherwise unable to fully interact with the device. However, as we have observed in banking trojans and other mobile threats, the accessibility services could also be abused by malware authors to perform malicious activities without user interaction. In recent versions of Android, Google limited the number of apps with accessibility services permission on Google Play and moved some functionality to other newly created APIs to minimize the abuse, but cyber criminals are still trying to exploit it, convincing users to activate this critical permission.

If accessibility permissions are granted, the trojan can fully perform its malicious activities; if it is not granted, it will still perform part of the possible commands such as ad-fraud, install short-cuts and update itself, opening the door to new payloads.

Fake Reviews

Based on the static analysis of the de-obfuscated second stage dex file (fields.css) it is possible to conclude that Android/LeifAccess can post fake reviews on Google Play by abusing the accessibility services:

Figure 3. De-obfuscated list of strings used as full qualified resource name of the view id access to perform fake reviews abusing accessibility services

Android/LeifAccess will try to download and install the target app because a user account only can write reviews of apps that have previously been installed. It will try to download through Google Play but there is also an implementation to download apps from an alternative market store (APKPure), as well as direct links.

Real World Example

As a real-world example of this malicious behavior it is possible to find reviews on Google Play that match with the parameters received from the C&C and stored in the de-obfuscated SharedPreferences XML files. For instance, the app ‘Super Clean-Phone Booster, Junk Cleaner & CPU Cooler’ is ranked with 4.5 stars average and more than 7k reviews, many of which are fake as they feature duplicated phrases copied from the Trojan’s command parameters.

 

Some of the fake comments contain multiple likes that could be associated to other commands performed by this malware which is able to find this text content and gives them a like:

Figure 6. Command “rate_words” that are used to vote for fraudulent reviews

Commands and Parameters Decryption

Android/LeifAccess.A stores a Hashtable map, in a SharedPreferences XML format, where the key is the function name and the value is the parameter used by the commands. To avoid detection, the real function names (plain text) and parameters are obfuscated, encrypted, salted and/or one-way hashed (md5 or sha-1).

• Values are stored as obfuscated strings using data compression with zip.deflater and base64.enconde as defense evasion techniques. Some strings are obfuscated more than one time with the same algorithm.
• Each key is calculated using an md5 digest checksum of the byte array produced by a custom base64 of the string resulting from a custom operation over ‘function names’ and ‘package name’ of the sample. There are hundreds of different variants of this family, each one with a different package name, so malware authors take advantage of this uniqueness in the string of the package name to use it as a salt for hashing the key values.

In figure 5 the xml <String> element contains the reviews sent by the C&C while the attribute “name” represents the hash table key. In this example the key “FF69BA5F448E26DDBE8DAE70F55738F6” is associated to the command “rate_p_words”:

MD5 is a one-way function so it is not possible to decrypt the string but, based on the static analysis, it is possible to recalculate the hash for all the decoded strings found on the second stage DEX file and then associate it with the hash-table.

Recalculation of this particular hash was possible by invoking the hash function with rate_p_words and com.services.ibgpe.hflbsqqjrmlfej as arguments.

In the same hash table other parameters are stored, such as the self-update server URL using the same encryption/obfuscation technique:

Figure 7. Obfuscated HashMap

This key F09EA69449BA00AA9A240518E501B745 and the embedded value can be interpreted as follows:

Figure 8. HashMap as plain text

Other commands are detailed in the table of commands in the appendix which includes shortcut creation and frequency of updates.

Furthermore, received commands may also be stored locally in an SQLite DB that logs part of the action performed by the malware.

Abuse of Accessibility

Deactivating Google Play Protect:

LeifAccess tries to navigate through the target app using AccessibilityNodeInfo by view-id resource name. For example, for Google Play Protect, the package is embedded on the Google Play app with package name ‘com.android.vending’ and it will try to access the view id ‘play_protect_settings:’ as defined on string g. The full qualified resource id is “com.android.vending:id/play_protect_settings” as shown in the deobfuscated code below. Then it will locate the ‘android:id/switch_widget’ to try to deactivate the scan device option.

Figure 9. List of view-id resources strings abused by LeifAccess

Fake Account Creation Abusing Single Sign On:

Another monetization technique used by this family is the creation of accounts in the name of real user identities and accounts registered on the infected device. This is achieved by abusing the accessibility services to perform an account creation and login with the Google Sign-In OAuth 2.0 that many legitimate services integrate in their apps.

Android/LeifAccess can download and install the target app to later set up an account without user interaction.

The deobfuscated code below shows how Android/LeifAccess uses AccesibilityEvent to navigate into a dating app to create an account using the Google login option.

Figure 10. AccessibilityEvent used to create fake accounts

Below are some examples of other application package names that are targeted by this malware to perform fake account creation, mostly related to categories such as shopping, dating and social.

• zalora.android
• tiket.gits
• b2w.submarino
• zzkko
• phrendly
• newchic.client
• com.netshoes.app
• makemytrip
• like
• lazada.android
• joom
• jabong.android
• startv.hotstar
• banggood.client
• alibaba.intl.android.apps.poseidon
• alibaba.aliexpresshd
• airyrooms.android

Other Malicious Payloads

Ad Fraud:

Clicker functionality is also implemented so advertisement traffic is requested by the infected device without showing a single ad in the interface.

Specific user-agent headers are sent from C&C to perform ad-fraud.

Figure 11. Specific User-Agent

The ID for the ad network is updated via the C&C Server:

Figure 12. ID used to monetize the ads

Normally, the apps that run ads integrate one or more ad network SDKs (usually distributed as JAR libraries) into it to properly request the ad content gathering location, device type or even some user data. However, this malware does not integrate any SDK packages into the source code to access the ads. Android/LeifAccess can load ads using the proper ad-network format via direct links for Ad Clicks or Ad Impressions (IMPR) that the C&C server pre-builds and sends to it in JSON format. This means that the infected device will be able to request a URL with the full parameters required to simulate a legitimate click coming from a user clicking a banner in the context of a legitimate application, evading the SDK integration which also contributes to keep a relatively small file size.

The adware JSON structure includes:

 

Furthermore, this malware can show real ads in full screen out of the context of any app after unlocking the device if it receives the proper commands, or based on a certain frequency defined by the C&C. Also, it can show an overlay icon redirecting to ads as a floating overlay.

Arbitrary shortcuts can be created in the home screen based on the parameters received:

 

Fake Notifications

To gain accessibility services or to request the deactivation of an OS security option that has not been granted yet, the malware is able to launch toast messages to try to convince victims to perform certain actions.

Below is a list of fake notifications, including title and content, in JSON format used by the malware inside the “dialog” attribute which is executed as a toast notification in the intervals of the parameter “notifi_inter” (28800000 milliseconds, which equals 8 hours).

Figure 13. List of dialogs used as fake notifications

The ‘deactivate’ and ‘activate’ string is internationalized to match with the OS language:

 

Unpacking and Execution

To avoid detection, or as a ‘defense evasion’ technique, the original installed application is just a wrapper that, once executed, can decrypt a JAR from the asset file from path ‘assets/fields.css’ which is dynamically loaded using reflection into the main application. System API calls strings are also obfuscated using a custom base64 implementation.

Figure 14. Overview of the malware unpacking

Reversing the decrypted jar file requires deobfuscation of the strings used by Android/LeifAccess.A which are all custom encoded:

Figure 15. Deobfuscated strings using function et.a

Command and Control Server:

The command and control servers are also used for malware distribution and payload updates. The domain names contain words that can make people think they belong to a legitimate advertisement network or a Content Delivery Network (CDN):

hxxp://api.adsnativeXXX.com

hxxp://cdn.leadcdnbXXX.com/

Distribution and Telemetry

Distribution

The samples are available in the C&C hosted as direct APK links but also may be distributed in social media or as a malvertising campaign that tries to convince users to install a critical security update. This variant label is SystemSecurityUpdates and the package name starts with ‘com.services.xxxx’, pretending to be a system update.

Variants of Android/LeifAccess.A were found hosted and distributed through the Discord game chat platform. Some malicious APK variants were available in the following URL scheme:

• hxxps://cdn.discordapp.com/attachments/XXXXXXXXX/XXXXXX

Infection requires the user to download and install the malicious APK; this means that a social engineering component is used for initial access. Scaring people about potential threats using ads, or luring gamers that want to add a  “hidden feature” makes them more willing to follow the instructions of untrusted installation flows described by attackers on posts or videos, even if they must dismiss security notifications or deactivate security measures to allow aggressive permissions or activate accessibility services.

Conclusion

The ability to install apps and then post fake reviews on Google Play in the name of a victim, create fake accounts on third party services plus the self-update mechanism, in conjunction with multiple obfuscation and encryption techniques used as self-defense, makes this piece of malware unique and allowed it to stay under the radar for victims without AV protection.

The main functions of this Trojan can be described as:

• Download Apps from Google Play or APK Pure
• Deactivate Google Play Protect
• Create Fake Accounts with OAuth abusing accessibility
• Post fake reviews on Google Play
• Create short cuts on the main screen
• Display Ads in the background and in full screen
• Self-Update

Android/LeifAccess implements multiple techniques for self-defense to encrypt and obfuscate the malicious behavior and to try to avoid AV detection.

Due to the high volume of unique samples we can infer that a considerable amount of resources are destined to infrastructure and automation for sample generation in a server-side polymorphic way.

New variants are constantly deployed to keep this mobile botnet of fake reviewers alive.

This kind of malware not only damages users, it also affects App Market credibility and adversaries/ad-networks that paid for banners that nobody views.

It also suggests that a market exists for the fraudulent improvement of app reputation, and services such as this must be performed with a monetization objective very similar to what happens on social media where services exist to buy followers or likes.

These publications violate the guidelines of the Google Play Store mainly because reviews and rankings are key to helping users to select appropriate and safe apps – fake ones can ruin users’ trust.

However, this ranking manipulation is a challenge to identify and remove as these kinds of fake review are not produced by fake accounts and most anti-spam methods are designed to find content created by untrusted or unverified accounts rather than legitimate users. This same technique could be used for social media or any other platform distribution of arbitrary messages.

If you think you could be affected by this family then you can view or edit the reviews that you have written on your Google account at https://aboutme.google.com/.

Newer implementations of this malware are also identified and detected by McAfee Mobile Security as Android/LeifAccess.A and Android/LeifAccess.B.

Technical Data and IOCs

Table of Commands

Mitre ATT&CK Matrix

IoCs

6032c1a8b54f3daf9697a49fdd398d3ebe35f3fec3d945d6d8e9588043332969

com.services.ibgpe.hflbsqqjrmlfej

032184204b50f0634ad360a2090ea9904c012cb839b5a0364a53bf261ce8414e

com.services.kxyiqc.zzwkzckzfiojjzpw

0a95e9cce637a6eb71e4c663e207146fe9cde0573265d4d93433e1242189a35c

com.services.jifat.qaxtitmumdd

533a395ed16143bbe6f258f3146ea0ea3c56f71e889ace81039800803d0b1e18

com.services.xvpyv.tteawsribdsvi

6755f708d75a6b8b034eae9bcb6176679d23f2dc6eb00b8656d00f8ee0ec26c1

com.services.myzmuexri.nrphcanr

 

URLS

adsnative123[.]com

Myapkcdn[.]in

adsv123[.]com

 

References

https://android-developers.googleblog.com/2018/12/in-reviews-we-trust-making-google-play.html

The post Android/LeifAccess.A is the Silent Fake Reviewer Trojan appeared first on McAfee Blog.

In our first article we discussed the growing pattern of targeted ransomware attacks where the first 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 this second part we will pick up where we left off: the attacker has a foothold on the network by controlling an infected host or has a valid account to access a remote service.

With either a valid account or having access towards a system in a company, the first two things you want to figure out are:

1. What kind of rights do I have from this machine?
2. Where the heck am I in this network?

One of the first commands you would observe as a responder is “whoami/all”. The output of this command will give the details of the account the attacker has on the machine with regards to group/privileges. A great way to detect suspicious activity in your network is to setup a detection rule for the “whoami” command and assign it to the assets in use by executives or holders of key positions in the company. There might always be a techie executive in the company but most of them will never use command or use a command-line.

In the context of the targeted ransomware attacks, the attacker preferably wants to have local-admin/domain-admin and or system rights. Those will be the keys to the kingdom and open all gates.

In the next step, mostly observe some variant from Mimikatz or other password-dumping tools that will dump the credentials from a machine. Either the tool Mimikatz is compiled in various formats or it is part of a remote PowerShell toolkit like Empire:

We began this article series with the fact that every touch of a system will leave digital footprints behind, in this example with Empire, the following is happening:

• Attacker has a connection to a system through usage of a ‘launch script’
• Attacker is using a C2 (command and control) to interact
• Attacker is using PowerShell to execute commands

From a MITRE ATT&CK Techniques perspective we would look at this overview of techniques and interaction:

Which stages and evidence sources will create visibility and early warning indicators?

For PowerShell usage there are several digital evidence locations available. Besides traces in memory, there can be traces discovered in the Windows Event logs, the Registry, on the file-system like the Prefetch directory and there’s even a PowerShell command history file available if a version of PowerShell v5 and above is used. That location can be found at:

C:\Users\<username>\AppData\Roaming\Microsoft\Windows PowerShell\PSReadline\ConsoleHost_history.txt 

Empire by design is encrypting its communications, makes infrequent and randomized connections and, last but not least, is mirroring HTTP activity to stay hidden in the ‘normal’ traffic. If we look at the order of volatility from our first article, network traffic will change from seconds to minutes, giving us a very short window unless we do full packet capture and inspection of our network traffic.

The network activity might be challenging to notice, however there are possible indicators that can help possible Empire traffic. To setup the C2 traffic, the attacker needs to configure a ‘listener’ that contains all the settings for the C2 traffic interaction.

In the partial setup screen in Figure 4, we see three URI’s being configured that will be frequently requested and combined with an HTTP Header. A combination detection of the three URI’s polled within x timeframe combined with the HTTP header could be a very good network-indicator to detect Empire C2 traffic. As a responder, when you detect these indicators, look back at Figure 3 and start hunting backwards. You discovered the C2 activity, but it means the hosts who are interacting with the C2 have PowerShell activity and time to secure your evidence. This is how I like to apply the MITRE ATT&CK model:  understand what you just discovered, and the implications  then hunt for evidence or anticipate the attacker’s next step and act.

Keep in mind this is a default setup and can be changed by the attacker. Experience suggests that cyber-crime motivated actors are in a hurry for the cash and use a default installation of tools, whereas nation-state cyber-espionage operations are customizing since they want to operate longer in a victim’s network.

Now back to our scenario. The attacker has acquired the right privileges and has laterally moved through the network to have an idea how large it is and have possibly identified critical assets — they love shared folders with a lot of data in them.

The attacker will next prepare a custom version of the ransomware and could have tested it on underground AV-testing services to make sure that it will be fully undetectable (FUD). Depending on skills and capabilities, the ransomware will either be uploaded to the victim’s network or using scripts distributed and executed over the network. We have observed cases where a series of .bat scripts were used and where the payload was downloaded from Pastebin and executed by PowerShell on hosts – enough variety and options. Once executed,  the first calls will come into the Helpdesk reporting the ransom notes.

A lot of the above techniques are available within post exploitation frameworks, of which there are several options that attackers can choose from. With any of these, the tool is only a conduit and we should always focus on detecting techniques rather than implementation specifics. Available options come in the form of both underground toolkits and penetration test tools designed to build awareness around the attacks. Unfortunately, those designed as security tools may also be used for nefarious purposes. This ‘chicken and egg’ situation is often the cause of heated debate since on one hand the tools can streamline attack scenarios, while on the other, without having them available to defenders, adequate testing of precautions is impossible.

Empire was mentioned above. This excellent PowerShell-based post-exploitation framework is no longer maintained or supported by its authors. Although forks exist, traction has slowed but its use is still detected. Cobalt Strike, a commercial adversary simulation platform regularly used by red teams to test infrastructural security measures and detection capacity, is increasingly being adopted by criminal actors.” Although its license is strictly controlled, pirated and cracked trial versions are available in the criminal underworld. Cobalt Strike is updated regularly to include the latest techniques and tools such as Mimikatz, while allowing a lot of flexibility for addition of new and unique attack and bypass techniques. This can increase the likelihood of success, even on the most recent operating system versions.

Threat groups distributing GoGalocker, MegaCortex and Maze ransomware have been observed utilizing Cobalt Strike. At this stage in our scenario, with a foothold on the network, Cobalt Strike provides many options which can be used to complete their objective. These include T1075 Pass the Hash, T1097 Pass the Ticket, T1105 Remote File Copy, T1021 Remote Services and the old reliable: T1077 Windows Admin Shares.

As detailed in part 1, this evidence remains on a system for differing time spans. By studying previous attacks, we can see a general mode of operation and a sequence in which these techniques are executed. This can help guide us when choosing the timing and methods of evidence collection.

Detection of these attacks is not an easy task. Exploitation frameworks are often open source, in which case the attacker can modify code to manipulate IOC’s (indicators of compromise). Alternatively, and as is the case for our example, Cobalt Strike, the framework will provide specific configuration around the final form of binary droppers, network traffic format, timing and specific parameters, etc. Therefore, generic signatures will only detect the most basic of attacks and, as previously mentioned, focusing on techniques and behaviors rather than tools becomes critical. Creating a Cobalt Strike generic detection may miss the point of its existence – education around malicious techniques and behaviors. However, we can learn a lot about various indicator categories that can be monitored for functional outliers and unusual behaviors and, where the tool is merged into malware strains, the markers for that specific instance can often become specific IOC’s.

In a lot of cases, understanding normal system behavior is crucial for uncovering outliers and having a baseline system for comparison can aid the analysis.

A few examples of these include:

• Memory
  • The holy grail. Binary droppers may be modified to mask their true intentions, however in memory they can be visible in a decoded format.
  • Search for markers of functionality such as suspicious system calls or reads/writes of sensitive system locations (e.g. lsass memory).
• Running Processes
  • Similarly, running processes can be very revealing.
  • Although process ‘migration’ is often carried out, review for abnormal process hierarchies.
  • Does the process carry out functionality that is not expected? E.g. does notepad make http requests to an external domain?
• Network Traffic
  • Domains should match known-good.
  • Spikes or regular timing patterns in traffic type or to specific servers.
  • Variables used in unusual manner, e.g. http headers including encoded binary data.
• Disk
  • Binary and configuration files available for reverse engineering.
  • This static analysis is not as powerful as dynamic, running software.
  • Debugging a malicious binary may help but beware of sandbox/debugger detection.
• Backup / Log Files
  • Never fully trust log files as attackers can easily falsify. External sources, e.g. syslog going to an external db, can improve the reliability of log data if available.
  • Search for specific markers for malicious activity. Some useful items to include: command line logs, PowerShell script block logging, specific logs for network applications such as web servers, service installation, share accessed – particularly C$, process launch, account login.

As we highlighted in the two articles, targeted ransomware attacks have increased massively over the past 8 months. Targeting MSPs to hit many at the same time, victims running critical operations, public services, etc. Many of them are all using a similar blueprint as we tried to highlight.

Learn from the articles, identify which technology can give you that visibility, what digital evidence sources do you have, and can you detect fast enough to preserve and respond? If the ‘initial access stage’ is passed, where can you pick up in your line of defense and stop the threat?

Stay tuned for part 3, where we discuss technical controls that are available to help your organization to react to these early warning signs within an acceptable timeframe.

The post CSI: Evidence Indicators for Targeted Ransomware Attacks – Part II appeared first on McAfee Blog.

The last several years have been fascinating for those of us who have been eagerly observing the steady move towards autonomous driving. While semi-autonomous vehicles have existed for many years, the vision of fleets of fully autonomous vehicles operating as a single connected entity is very much still a thing of the future. However, the latest technical advances in this area bring us a unique and compelling picture of some of the capabilities we might expect to see “down the road.” Pun intended.

For example, nearly every new vehicle produced in 2019 has a model which implements state-of-the art sensors that utilize analytics technologies, such as machine learning or artificial intelligence, and are designed to automate, assist or replace many of the functions humans were formerly responsible for. These can range from rain-sensors on the windshield to control wiper blades, to object detection sensors using radar and lidar for collision avoidance, to camera systems capable of recognizing objects in range and providing direct driving input to the vehicle.

This broad adoption represents a fascinating development in our industry; it’s one of those very rare times when researchers can lead the curve ahead of adversaries in identifying weaknesses in underlying systems.

McAfee Advanced Threat Research (ATR) has a specific goal: identify and illuminate a broad spectrum of threats in today’s complex landscape. With model hacking, the study of how adversaries could target and evade artificial intelligence, we have an incredible opportunity to influence the awareness, understanding and development of more secure technologies before they are implemented in a way that has real value to the adversary.

With this in mind, we decided to focus our efforts on the broadly deployed MobilEye camera system, today utilized across over 40 million vehicles, including Tesla models that implement Hardware Pack 1.

18 Months of Research

McAfee Advanced Threat Research follows a responsible disclosure policy, as stated on our website. As such, we disclosed the findings below to both Tesla and MobilEye 90 days prior to public disclosure. McAfee disclosed the findings to Tesla on September 27^th, 2019 and MobilEye on October 3^rd, 2019. Both vendors indicated interest and were grateful for the research but have not expressed any current plans to address the issue on the existing platform. MobilEye did indicate that the more recent version(s) of the camera system address these use cases.

MobilEye is one of the leading vendors of Advanced Driver Assist Systems (ADAS) catering to some of the world’s most advanced automotive companies. Tesla, on the other hand, is a name synonymous with ground-breaking innovation, providing the world with the innovative and eco-friendly smart cars.

 

As we briefly mention above, McAfee Advanced Threat Research has been studying what we call “Model Hacking,” also known in the industry as adversarial machine learning. Model Hacking is the concept of exploiting weaknesses universally present in machine learning algorithms to achieve adverse results. We do this to identify the upcoming problems in an industry that is evolving technology at a pace that security has not kept up with.

We started our journey into the world of model hacking by replicating industry papers on methods of attacking machine learning image classifier systems used in autonomous vehicles, with a focus on causing misclassifications of traffic signs. We were able to reproduce and significantly expand upon previous research focused on stop signs, including both targeted attacks, which aim for a specific misclassification, as well as untargeted attacks, which don’t prescribe what an image is misclassified as, just that it is misclassified. Ultimately, we were successful in creating extremely efficient digital attacks which could cause misclassifications of a highly robust classifier, built to determine with high precision and accuracy what it is looking at, approaching 100% confidence.

We further expanded our efforts to create physical stickers, shown below, that model the same type of perturbations, or digital changes to the original photo, which trigger weaknesses in the classifier and cause it to misclassify the target image.

This set of stickers has been specifically created with the right combination of color, size and location on the target sign to cause a robust webcam-based image classifier to think it is looking at an “Added Lane” sign instead of a stop sign.

In reality, modern vehicles don’t yet rely on stop signs to enable any kind of autonomous features such as applying the brakes, so we decided to alter our approach and shift (pun intended) over to speed limit signs. We knew, for example, that the MobilEye camera is used by some vehicles to determine the speed limit, display it on the heads-up display (HUD), and potentially even feed that speed limit to certain features of the car related to autonomous driving. We’ll come back to that!

We then repeated the stop sign experiments on traffic signs, using a highly robust classifier, and our trusty high-resolution webcam. And just to show how robust our classifier is, we can make many changes to the sign— block it partially, place the stickers in random locations — and the classifier does an outstanding job of correctly predicting the true sign, as demonstrated in the video above. While there were many obstacles to achieving the same success, we were ultimately able to prove both targeted and untargeted attacks, digitally and physically, against speed limit signs. The below images highlight a few of those tests.

At this point, you might be wondering “what’s so special about tricking a webcam into misclassifying a speed limit sign, outside of just the cool factor?” Not much, really. We felt the same, and decided it was time to test the “black box theory.”

What this means, in its most simple form, is attacks leveraging model hacking which are trained and executed against white box, also known as open source systems, will successfully transfer to black box, or fully closed and proprietary systems, so long as the features and properties of the attack are similar enough. For example, if one system is relying on the specific numeric values of the pixels of an image to classify it, the attack should replicate on another camera system that relies on pixel-based features as well.

The last part of our lab-based testing involved simplifying this attack and applying it to a real-world target. We wondered if the MobilEye camera was as robust as the webcam-based classifier we built in the lab? Would it truly require several highly specific, and easily noticeable stickers to cause a misclassification? Thanks to several friendly office employees, we were able to run repeated tests on a 2016 Model “S” and 2016 Model “X” Tesla using the MobilEye camera (Tesla’s hardware pack 1 with EyeQ3 mobilEye chip). The first test involved simply attempting to recreate the physical sticker test – and, it worked, almost immediately and with a high rate of reproducibility.

In our lab tests, we had developed attacks that were resistant to change in angle, lighting and even reflectivity, knowing this would emulate real-world conditions. While these weren’t perfect, our results were relatively consistent in getting the MobilEye camera to think it was looking at a different speed limit sign than it was. The next step in our testing was to reduce the number of stickers to determine at which point they failed to cause a misclassification. As we began, we realized that the HUD continued to misclassify the speed limit sign. We continued reducing stickers from 4 adversarial stickers in the only locations possible to confuse our webcam, all the way down to a single piece of black electrical tape, approximately 2 inches long, and extending the middle of the 3 on the traffic sign.

Even to a trained eye, this hardly looks suspicious or malicious, and many who saw it didn’t realize the sign had been altered at all. This tiny piece of sticker was all it took to make the MobilEye camera’s top prediction for the sign to be 85 mph.

 

The finish line was close (last pun…probably).

Finally, we began to investigate whether any of the features of the camera sensor might directly affect any of the mechanical, and even more relevant, autonomous features of the car. After extensive study, we came across a forum referencing the fact that a feature known as Tesla Automatic Cruise Control (TACC) could use speed limit signs as input to set the vehicle speed.

There was majority of consensus among owners that this might be a supported feature. It was clear that there was also confusion among forum members as to whether this capability was possible, so our next step was to verify by consulting Tesla software updates and new feature releases.

A software release for TACC contained just enough information to point us towards speed assist, with the following statement, under the Tesla Automatic Cruise Control feature description.

“You can now immediately adjust your set speed to the speed determined by Speed Assist.”

This took us down our final documentation-searching rabbit hole; Speed Assist, a feature quietly rolled out by Tesla in 2014.

Finally! We can now add these all up to surmise that it might be possible, for Tesla models enabled with Speed Assist (SA) and Tesla Automatic Cruise Control (TACC), to use our simple modification to a traffic sign to cause the car to increase speed on its own!

Despite being confident this was theoretically possible, we decided to simply run some tests to see for ourselves.

McAfee ATR’s lead researcher on the project, Shivangee Trivedi, partnered with another of our vulnerability researchers Mark Bereza, who just so happened to own a Tesla that exhibited all these features. Thanks Mark!

For an exhaustive look at the number of tests, conditions, and equipment used to replicate and verify misclassification on this target, we have published our test matrix here.

The ultimate finding here is that we were able to achieve the original goal. By making a tiny sticker-based modification to our speed limit sign, we were able to cause a targeted misclassification of the MobilEye camera on a Tesla and use it to cause the vehicle to autonomously speed up to 85 mph when reading a 35-mph sign. For safety reasons, the video demonstration shows the speed start to spike and TACC accelerate on its way to 85, but given our test conditions, we apply the brakes well before it reaches target speed. It is worth noting that this is seemingly only possible on the first implementation of TACC when the driver double taps the lever, engaging TACC. If the misclassification is successful, the autopilot engages 100% of the time. This quick demo video shows all these concepts coming together.

Of note is that all these findings were tested against earlier versions (Tesla hardware pack 1, mobilEye version EyeQ3) of the MobilEye camera platform. We did get access to a 2020 vehicle implementing the latest version of the MobilEye camera and were pleased to see it did not appear to be susceptible to this attack vector or misclassification, though our testing was very limited. We’re thrilled to see that MobilEye appears to have embraced the community of researchers working to solve this issue and are working to improve the resilience of their product. Still, it will be quite some time before the latest MobilEye camera platform is widely deployed. The vulnerable version of the camera continues to account for a sizeable installation base among Tesla vehicles. The newest models of Tesla vehicles do not implement MobilEye technology any longer, and do not currently appear to support traffic sign recognition at all.

Looking Forward

We feel it is important to close this blog with a reality check. Is there a feasible scenario where an adversary could leverage this type of an attack to cause harm? Yes, but in reality, this work is highly academic at this time. Still, it represents some of the most important work we as an industry can focus on to get ahead of the problem. If vendors and researchers can work together to identify and solve these problems in advance, it would truly be an incredible win for us all. We’ll leave you with this:

In order to drive success in this key industry and shift the perception that machine learning systems are secure, we need to accelerate discussions and awareness of the problems and steer the direction and development of next-generation technologies. Puns intended.

 

The post Model Hacking ADAS to Pave Safer Roads for Autonomous Vehicles appeared first on McAfee Blog.

Catherine Huang, Ph.D., and Shivangee Trivedi contributed to this blog.

The term “Adversarial Machine Learning” (AML) is a mouthful!  The term describes a research field regarding the study and design of adversarial attacks targeting Artificial Intelligence (AI) models and features.  Even this simple definition can send the most knowledgeable security practitioner running!  We’ve coined the easier term “model hacking” to enhance the reader’s comprehension of this increasing threat.  In this blog, we will decipher this very important topic and provide examples of the real-world implications, including findings stemming from the combined efforts of McAfee’s Advanced Analytic Team (AAT) and Advanced Threat Research (ATR) for a critical threat in autonomous driving.

1. First, the Basics

AI is interpreted by most markets to include Machine Learning (ML), Deep Learning (DL), and actual AI, and we will succumb to using this general term of AI here.  Within AI, the model – a mathematical algorithm that provides insights to enable business results – can be attacked without knowledge of the actual model created.  Features are those characteristics of a model that define the output desired.  Features can also be attacked without knowledge of the features used!  What we have just described is known as a “black box” attack in AML – not knowing the model and features – or “model hacking.”  Models and/or features can be known or unknown, increasing false positives or negatives, without security awareness unless these vulnerabilities are monitored and ultimately protected and corrected.

In the feedback learning loop of AI, recurrent training of the model occurs in order to comprehend new threats and keep the model current (see Figure 1).  With model hacking, the attacker can poison the Training Set.  However, the Test Set can also be hacked, causing false negatives to increase, evading the model’s intent and misclassifying a model’s decision.  Simply by perturbating – changing the magnitudes of a few features (such as pixels for images), zeros to ones/ones to zeros, or removing a few features – the attacker can wreak havoc in security operations with disastrous effects.  Hackers will continue to “ping” unobtrusively until they are rewarded with nefarious outcomes – and they don’t even have to attack with the same model that we are using initially!

2. Digital Attacks of Images and Malware

Hackers’ goals can be targeted (specific features and one specific error class) or non-targeted (indiscriminate classifiers and more than one specific error class), digital (e.g., images, audio) or physical (e.g., speed limit sign).  Figure 2 shows a rockhopper penguin targeted digitally.  A white-box evasion example (we knew the model and the features), a few pixel changes and the poor penguin in now classified as a frying pan or a computer with excellent accuracy.

While most current model hacking research focuses on image recognition, we have investigated evasion attacks and mitigation methods for malware detection and static analysis.  We utilized DREBIN[1], an Android malware dataset, and replicated the results of Grosse, et al., 2016[2].  Utilizing 625 malware samples highlighting FakeInstaller, and 120k benign samples and 5.5K malware, we developed a four-layer deep neural network with about 1.5K features (see Figure 3).  However, following an evasion attack with only modifying less than 10 features, the malware evaded the neural net nearly 100%.  This, of course, is a concern to all of us.

 

 

 

Using the CleverHans[1] open-source library’s Jacobian Saliency Map Approach (JSMA) algorithm, we generated perturbations creating adversarial examples.  Adversarial examples are inputs to ML models that an attacker has intentionally designed to cause the model to make a mistake[1].  The JSMA algorithm needs only a minimum number of features need to be modified.  Figure 4 demonstrates the original malware sample (detected as malware with 91% confidence).  After adding just two API calls in a white-box attack, the adversarial example is now detected with 100% confidence as benign. Obviously, that can be catastrophic!

 

In 2016, Papernot[5] demonstrated that an attacker doesn’t need to know the exact model that is utilized in detecting malware.  Demonstrating this theory of transferability in Figure 5, the attacker constructed a source (or substitute) model of a K-Nearest Neighbor (KNN) algorithm, creating adversarial examples, which targeted a Support Vector Machine (SVM) algorithm.  It resulted in an 82.16% success rate, ultimately proving that substitution and transferability of one model to another allows black-box attacks to be, not only possible, but highly successful.

 

In a black-box attack, the DREBIN Android malware dataset was detected 92% as malware.  However, using a substitute model and transferring the adversarial examples to the victim (i.e., source) system, we were able to reduce the detection of the malware to nearly zero.  Another catastrophic example!

3. Physical Attack of Traffic Signs

While malware represents the most common artifact deployed by cybercriminals to attack victims, numerous other targets exist that pose equal or perhaps even greater threats. Over the last 18 months, we have studied what has increasingly become an industry research trend: digital and physical attacks on traffic signs. Research in this area dates back several years and has since been replicated and enhanced in numerous publications. We initially set out to reproduce one of the original papers on the topic, and built a highly robust classifier, using an RGB (Red Green Blue) webcam to classify stop signs from the LISA[6] traffic sign data set. The model performed exceptionally well, handling lighting, viewing angles, and sign obstruction. Over a period of several months, we developed model hacking code to cause both untargeted and targeted attacks on the sign, in both the digital and physical realms. Following on this success, we extended the attack vector to speed limit signs, recognizing that modern vehicles increasingly implement camera-based speed limit sign detection, not just as input to the Heads-Up-Display (HUD) on the vehicle, but in some cases, as input to the actual driving policy of the vehicle. Ultimately, we discovered that minuscule modifications to speed limit signs could allow an attacker to influence the autonomous driving features of the vehicle, controlling the speed of the adaptive cruise control! For more detail on this research, please refer to our extensive blog post on the topic.

4. Detecting and Protecting Against Model Hacking

The good news is that much like classic software vulnerabilities, model hacking is possible to defend against, and the industry is taking advantage of this rare opportunity to address the threat before it becomes of real value to the adversary. Detecting and protecting against model hacking continues to develop with many articles published weekly.

Detection methods include ensuring that all software patches have been installed, closely monitoring drift of False Positives and False Negatives, noting cause and effect of having to change thresholds, retraining frequently, and auditing decay in the field (i.e., model reliability).  Explainable AI (“XAI”) is being examined in the research field for answering “why did this NN make the decision it did?” but can also be applied to small changes in prioritized features to assess potential model hacking.  In addition, human-machine teaming is critical to ensure that machines are not working autonomously and have oversight from humans-in-the-loop.  Machines currently do not understand context; however, humans do and can consider all possible root causes and mitigations of a nearly imperceptible shift in metrics.

Protection methods commonly employed include many analytic solutions: Feature Squeezing and Reduction, Distillation, adding noise, Multiple Classifier System, Reject on Negative Impact (RONI), and many others, including combinatorial solutions.  There are pros and cons of each method, and the reader is encouraged to consider their specific ecosystem and security metrics to select the appropriate method.

5. Model Hacking Threats and Ongoing Research

While there has been no documented report of model hacking in the wild yet, it is notable to see the increase of research over the past few years: from less than 50 literature articles in 2014 to over 1500 in 2020.  And it would be ignorant of us to assume that sophisticated hackers aren’t reading this literature.  It is also notable that, perhaps for the first time in cybersecurity, a body of researchers have proactively developed the attack, detection, and protection against these unique vulnerabilities.

We will continue to add to the greater body of knowledge of model hacking attacks as well as ensure the solutions we implement have built-in detection and protection.  Our research excels in targeting the latest algorithms, such as GANS (Generative Adversarial Networks) in malware detection, facial recognition, and image libraries.  We are also in process of transferring traffic sign model hacking to further real-world examples.

Lastly, we believe McAfee leads the security industry in this critical area. One aspect that sets McAfee apart is the unique relationship and cross-team collaboration between ATR and AAT. Each leverages its unique skillsets; ATR with in-depth and leading-edge security research capabilities, and AAT, through its world-class data analytics and artificial intelligence expertise. When combined, these teams are able to do something few can; predict, research, analyze and defend against threats in an emerging attack vector with unique components, before malicious actors have even begun to understand or weaponize the threat.

For further reading, please see any of the references cited, or “Introduction to Adversarial Machine Learning” at https://mascherari.press/introduction-to-adversarial-machine-learning/

 

 

[1] Courtesy of Technische Universitat Braunschweig.

[2] Grosse, Kathrin, Nicolas Papernot, et al. ”Adversarial Perturbations Against Deep Neural Networks for Malware Classification” Cornell University Library. 16 Jun 2016.

[3] Cleverhans: An adversarial example library for constructing attacks, building defenses, and benchmarking both located at https://github.com/tensorflow/cleverhans.

[4] Goodfellow, Ian, et al. “Generative Adversarial Nets” https://papers.nips.cc/paper/5423-generative-adversarial-nets.pdf.

[5] Papernot, Nicholas, et al. “Transferability in Machine Learning: from Phenomena to Black-Box Attacks using Adversarial Samples”  https://arxiv.org/abs/1605.07277.

[6] LISA = Laboratory for Intelligent and Safe Automobiles

The post Introduction and Application of Model Hacking appeared first on McAfee Blog.

For many years now I have been working and teaching in the field of digital forensics, malware analysis and threat intelligence. During one of the classes we always talk about Lockard’s exchange principle: “with contact between two items, there will be an exchange”. If we translate that to the digital world: “when an adversary breaches a system, they will leave traces of evidence behind”. The challenge is often how to discover that evidence in a timely manner to take action and discover what sources are available for detection. The volatile evidence sources must be secured as soon as possible while the non-volatile sources have a lower priority. An example of order of volatility:

In this series of two articles, you will see an example we have been observing as a concerning trend over the last couple of months.

In the first stage, companies are infected by some sort of information-stealing malware (Azorult, Dridex, Trickbot), or breached by having a weakly secured RDP server at the edge of the network.

Stage two occurs a few weeks later when the same victim is hit by a targeted ransomware campaign using Ryuk, Bitpaymer or another ransomware family the attacker has access to.

A recent example was covered by the team in this article on Bitpaymer. The adversary executing stage one does not necessarily have to be the same as the actor executing stage two. There are plenty of credentials harvested by Azorult or RDP on underground markets. Below is a screenshot from an advertiser demonstrating the number of Azorult victims (13k) they have made, including the information stolen from them:

Stage 1: The Initial Infection

Although there might be some variations, the graphical overview demonstrates how most of these attacks start. Whether by a drive-by compromise where a user visits a website infected with a malicious script or a spear-phishing campaign, the result is a malware infection that steals credentials, exfiltrates them and results in having valid accounts of the victim. The other scenario is buying the valid account information from the underground. Having valid accounts will give access toward a remote service or direct access to a victim’s machine using the malware. When an adversary makes the next move, 9 out of 10 times we observe the usage of a credential dumping tool like Mimikatz, or PowerShell related activity again for password dumping. The goal? To get local-admin, domain-admin or system rights on a system within the victim’s network. The secondary goal we observe with the usage of PowerShell tools/scripts is conducting reconnaissance of the network.

Digital Evidence Initial Access stage:

T1189 Drive-By Compromise

In this scenario the victim most likely browses the Internet and visits a webpage that contains a malicious script. Following the order of Volatility, where could we discover evidence? Depending on what type of actions are defined in the malicious script, it could leave traces on disk or in memory when injected.

T1192 & T1193 Spear-phishing Link/Attachment

In this scenario, the victim receives an email with a link (T1192) or a weaponized attachment (T1193). By clicking on the link, a website is opened, and follow-up actions are executed as described above in the T1189 Drive-by compromise. The order of volatility is similar but will have a larger chain of execution. Since the user initiated the action, more digital evidence will be available on the victim’s machine:

1. Execution of a program (Email-client)
2. Clicking on the link will open the default configured Web-browser
3. Web-browser visits link
4. Script will execute

For the execution of a program and launch, there is process evidence, the prefetch directory, UserAssist, Shimcache, RecentApps and many more sources to track when they were launched and executed. The email itself can either be retrieved from the victim’s inbox or, in the case of Webmail, there might be remnants of it in the temporary Internet files. Most of the mentioned evidence artifacts are non-volatile and easy to extract in a forensically sound matter.

In the case of a spear-phishing attack with a weaponized attachment, the flow will look mostly similar to below (of course there are variations):

1. Execution of a program (Email-client)
2. Opening attachment
3. Launch of Office application
4. Execution of the macro
5. PowerShell/WMIC followed by Internet traffic downloading file
6. Execution of script/file
7. Execution in memory or written to disk and execution

We already discussed the non-volatile evidence available for the execution of a program. In this example there will be evidence for the launch/execution of the email-client and the opening of an Office application to execute the attachment. In case the attachment was opened before saving to disk, in Outlook the file was copied to the “SecureTemp” folder which is a hidden folder under Temporary Internet files.

Depending on the payload of the macro, evidence will exist of Internet related traffic. When PowerShell or WMIC is used, the launch of it is recorded in the Windows Prefetch directory and there are traces in the registry and/or event logs. Depending on what type of script or file is executed, traces can be discovered in memory or on disk, with memory most volatile and disk non-volatile.

When, for example, a malware like Azorult is installed on the victim’s machine, the flow will look like this:

The exfiltration of the data is mostly happening over TCP port 80 towards a C2 (command and control) dashboard, as demonstrated in Figure 1. Both T1043 and T1041 are techniques that will most likely leave non-volatile traces behind in network logs from devices like a proxy/gateway/firewall.

What we notice often is that infections with, for example, AZORULT are ignored/underestimated. They are being detected and the infection is either blocked or detected and later cleaned, however the capabilities of the malware are underestimated/ignored.

If we look again to table 1, the order of Volatility, the timeframe in which we operate is seconds to minutes with regards to initial network traffic and running of processes. Between infection and exfiltration is again in the timeframe of minutes, more than enough to exfiltrate credentials before an action was taken. This is also the delta in which we have the challenge – are our people, processes and technology combined capable of responding within this attack-window? Anticipating early warning signs and understanding the malware’s capabilities can assist in preventing larger damage.

What happens when the initial compromise results in having valid credentials or victim access through the RAT (random access Trojan), being used for a targeted ransomware attack? We will discuss that in the next article.

 

 

The post CSI: Evidence Indicators for Targeted Ransomware Attacks – Part I appeared first on McAfee Blog.

A Windows Linux Subsystem Interop Analysis

Following our research from Evil Twins and Windows Linux Subsystem, interoperability between different WSL versions was something that caught our attention. The protocol and mechanism to do file management from/to WSL is a must for Blue and Red Teams whose research will provide new ways to execute known techniques to achieve tactics such as Persistence, Defense Evasion and Execution, among others.

It is important (even if not seen today in regular arsenals) to understand how to protect, detect and react to this attack surface which could be widely spread in the future where WSL could be a de-facto component in every Enterprise machine.

Since Windows 10 version 1903, it is possible to access Linux files from Windows by using the \wsl$[DistroName] path syntax using 9P protocol. During our research, we found some design issues in WSLv1 that were propagated to WSLv2 — even though the core component differs. The main issue involves the lack of security control in the WSL communication object, leading to any user owning the instance to own the listening Planet 9 File System server. At first sight, this may look obvious, but once you control that communication, different ways of using the data being sent back and forth from Windows to the container begin to emerge.

It is important to mention that when running inside an isolated environment like WSLV2, certain activities not crossing boundaries may remain hidden for security products, but once an attempt to execute a malicious app on the Windows side is detected, the scanning mechanism provided by MVISION Endpoint and ENS will trigger to protect. MVISION EDR will provide visibility and detection on some of these artifacts. At the end of this article, we present certain objects to monitor to detect such cases in your organization.

Potential usages for Red Teams and  Researchers:

• Persistence by hiding the real content, especially on WSLv2 where the root folder is a VHDX image.
• Protocol fuzzing for discovering vulnerabilities on the implementation.
• Security bypass by using \\wsl$ syntax in applications that have options to disable Network Folders scan and thus, do not consider this as a local path. (McAfee MVision Endpoint will consider this special path).
• File tampering (the user accesses a file expecting some content, but it is changed during the transfer).

P9 Server Hijack Pre-Requisites:

• WSL Enabled
• Same user privileges as the WSL instance
• A P9 compatible server

In the following section P9 (Planet 9 File System Protocol) and 9P (the protocol) are used interchangeably

WSLv1 and P9

The communication is done using an AF_UNIX socket (local file) that is currently owned by the user executing the WSL instance. The socket is created by the custom init process. Processes from the Windows side use a p9driver to access that socket by using an implementation of the P9 FileSystem instead of accessing the files as “Windows local”.

Note: Plan 9 has several implementations; currently the format supported by Windows is L / W.

A simple string on init shows that:

1. The first WSL instance will open the p9 server for that distribution.
2. Init has an embed server that creates a Unix socket into the distro path.
3. The Unix socket is used to communicate.
4. Whenever \\wsl$\ is accessed, P9 driver starts the communication.
5. A P9 client communicates with the server.

Now, is that fsserver file protected? No! That means that we can hijack that socket and start our P9 server (in this case, I used DIOD as the main source) and from there… the options are endless from protocol fuzzers to trigger something unexpected, to protection bypass, to something very simple that just serves different content than expected.

To find programmatically the fsserver root location using PowerShell:

From there, the next step would be to start our p9 server from WSL (assuming the path was provided as the script argument as shown above):

In this example, next time we access \\wsl$\Debian, it will serve the files from mynewroot.

The below screenshot shows the full procedure using a modified P9 server:

1. DIOD listening on the local socket.
2. WSL directory listing before the hijack.
3. WSL directory listing after the hijack.

At the time we were working on this, WSLv2 was announced and available in the latest Win10 Update. The next question was obvious—can we still do the same, given that the instance is now hosting a real kernel due to its nature of being hosted as a Hyper-V internal instance?

WSLv2 and P9

Now that there is a Linux Kernel the real “p9 Linux” module is activated. C: drive is mounted using P9 with several rdfd/wdfd arguments on top of drvfs.

The host is at CID:2, and ports  50000/1/2 are used for InterOp Messages and instance control.

Back to work — there are some steps to follow to determine whether we can achieve the same P9 Server Hijack or not.

• Scan open ports listening on WSLv2 instance (a starting point could be modifying sample client code to became a scanner).

1. Find the instance UID (an option is to check the task manager and wslhost.exe command line).
2. Scan the instance!

3. Hey! Port 0x405(1029d) is open, let us Knock-Knock to find who is there.

• P9 server port found… let us go hijack!!!
  1. Listening to the same port as with WSLv1 is not possible , unless we find a way to bypass the restrictions (app/module not using reuseaddr/port, not possible to close from user-space, etc.).
  2. We cannot kill init nor unload the module serving the files, so our best bet would be to close the port from the kernel. At the end of the day, it is our instance and we login as root .
  3. Let us create a vsock module that will:
     1. List current vsock connected sockets.
     2. Close a socket listening on a certain port.

1. Compile the module using kernel source.
2. Test it! (Note that same ports are not present and should be fixed, but for what we want the output is enough).

3)   Now, we are free to go, but still, we need to start our P9 DIODserver listening somehow on that port using a VSOCK socket. Since `socat` supports this type of socket it will be a piece of cake.

• Access \\wsl$\DistributionName and voila!

Protection and Detection with McAfee Products

In Addition to rules related to WSL presented in previous posts, McAfee products provide several ways to detect and protect against P9 hijacking:

• MVISION Endpoint will scan \\wsl$\ even if network scanning is disabled, so from the execution perspective on Windows side protection will still apply.
• By using Endpoint Security Expert Rules it’s possible to block execution from WSL paths.
• To configure Active Response (WSLv1) follow the below steps:
  • Setup a trigger to be notified of this situation a file fsserver is deleted.
    • File Trigger with condition: Files name equals fsserver”
  • Files collector if enabled, looking for fsserver modifications.
    • “Files where Files name equals fsserver”

In MVISION EDR (WSLv1), the file collector should be enabled and looking for wsl.conf modifications (files where files name equals “fsserver”

As a final note, we expect this post to provide new insights about the future exploration of these key areas, mostly considering that WSLv1 and WSLv2 can be converted online and both versions will be fairly used during the next years.

References:

1. http://doc.cat-v.org/plan_9/misc/ubiquitous_fileserver/
2. http://9p.io/magic/man2html/5/intro
3. https://github.com/chaos/diod/blob/master/protocol.md
4. https://w4mhi.wordpress.com/complete-hyper-v-socket-client-code/
5. https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/make-integration-service
6. https://tyranidslair.blogspot.com/2019/07/digging-into-wsl-p9-file-system.html
7. https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/using-expert-rules-in-ens-10-5-3-to-prevent-malicious-exploits/
8. https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/the-twin-journey-part-1/

 

The post Knock, Knock – Who’s There? appeared first on McAfee Blog.

Intelligence became an integral military discipline centuries ago. More recently, this practice evolved into what is called Intelligence Preparation of the Battlefield, or IPB. In both military and civilian agencies, the discipline uses information collection followed by analysis to provide guidance and direction to operators making tactical or organizational decisions. Used strategically, this type of intelligence puts an organization in a stronger position to operate offensively or defensively because in theory, they now know more than their enemy.

This same concept can be applied in the theater of cybersecurity operations. However, the current scope of intelligence in many enterprises describes just one aspect of the IPB discipline: information collection. The critical component missing to complete the process is a specialized researcher trained in this type of analysis and subsequent application of intelligence.

A disciplined intelligence cycle goes deep—applying advanced data collection methodologies from open, closed and propriety sources, social media, human intelligence and the dark web against areas such as cybercrime, hactivism, or cyber espionage to thoroughly analyze the adversary. Intelligence can ultimately be used to prepare organizations tactically and strategically to both anticipate and mitigate modern threats.

The latest research and analysis from McAfee Advanced Program Group (APG) researcher Anne An detailing the actions of Chinese non-state threat actor groups is a great example of intelligence that is invaluable for organizations. This unique take on Chinese cyber criminality educates practitioners on the threats around them, empowering them to prepare their organization to be proactive, rather than reactive. Further, there are many times where organizations are unaware they have been a victim of a cyberattack. This could include stolen data, which McAfee APG may find being sold on the dark markets, and in some cases, could have a devastating effect on their business.

Sun Tzu, the Chinese general, and military strategist once articulated, “The art of war teaches us to rely not on the likelihood of the enemy’s not coming, but on our own readiness to receive him; not on the chance of his not attacking, but rather on the fact that we have made our position unassailable.”  These ancient words are still very meaningful today. If organizations robustly embrace the intelligence process, their defensive posture will exponentially improve.

 

The post Intelligence in the Enterprise appeared first on McAfee Blog.

Preface

Because of its longevity and technical sophistication, the Russian cybercriminal underground has long been the benchmark for threat researchers focused on studying cybercrime tactics and techniques; there is a plethora of publications dedicated to analyzing its economy and hacking forums. However, only a handful of studies have centered on the emerging threats and trends from other, less prominent, cybercriminal undergrounds.

Recent data shows that the Chinese cybercriminal underground’s profits exceeded US$15.1 billion in 2017, while causing more than $13.3 billion worth of damage relating to data loss, identity theft and fraud. Over the years, the McAfee Advanced Programs Group (APG) has observed Chinese non-state threat actor groups gradually transform from small local networks targeting mostly Chinese businesses and citizens to large, well-organized criminal groups capable of hacking international organizations.

The development of commercial-scale exploit toolkits and criminal networks that focus on monetization of malware have amplified the growing risks of cybercrime in the Asia Pacific region to include a DDoS attack against the People’s Bank of China in December 2013, a $1 billion SWIFT hack against Bangladesh Bank in February 2016 and a $60 million theft from Far Eastern International Bank in Taiwan in October 2017, to name just a few.

This blog provides a rare glimpse inside the Chinese cybercriminal underground. Analyzing its current business models and techniques has yielded insights into the drastic changes in its operations, including the tactics and strategies it is borrowing from Russian cybercriminals.

Timeline: The Rise of the Chinese Cybercriminal Underground

China established its first cable connection to the world wide web in 1994, around the same time as cybercrime syndicates from Russia and other emerging cybercriminal undergrounds were executing their first major cybercrimes. Chinese leaders have since prioritized the development and acceleration of Internet technologies and, today, the size of China’s Internet use is massive and unparalleled at 800 million users.

However, this growth in Internet usage is not without irony as it has been accompanied by a significant increase in cybercriminal activity. Despite the Chinese government placing high importance on running one of the world’s most sophisticated Internet censorship systems, local cybercriminals are finding workarounds that contribute to China having one of the fastest growing cybercriminal underground economies.

China’s cybercrime enterprise is large, lucrative and expanding quickly. According to 2018 Internet Development Statistics, China’s cybercriminal underground was worth more than US $15 billion, nearly twice the size of its information security industry. The same Chinese-language source also shows that China’s cybercrime is growing at a rate of more than 30 percent a year. An estimated 400,000 people work in underground cybercriminal networks.

Changes in Tactics, Techniques and Procedures

In order to quickly scale up their businesses and maximize return on investment (ROI), Chinese cybercriminals have continuously adapted their tactics, techniques and procedures (TTPs). One significant change is that Chinese cybercriminals are slowly moving away from a high degree of one-to-one engagement through China’s popular QQ instant messaging platform to now establishing more formal cybercriminal networks. These networks use centralized advertising and standard service processes similar to Russian and other more sophisticated cybercriminal underground forums. Cybercriminals can access these centralized networks hosting on the deep web to post their products and services. A large amount of stolen data is available via automated services, where carders can order the credit and debit card information they want without having to interact with another user. With regard to hacking services, Chinese cybercriminals also offer modules for prospective clients to fill out their service requests, including types of attacks, target IP addresses, desirable malware or exploit toolkits and online payment processing. Through establishing a standardized model of sale, Chinese cybercriminals can expand their activity quickly without incurring additional overhead costs.

Attacks-as-a-service

Similar to other prominent cybercrime underworlds, Chinese cybercriminal underground markets are focused on providing excellent customer service. Many of the hackers expand their working hours to include weekends and even provide 24/7 technical support for customers who do not have a technical background. Distributed Denial of Service (DDoS) botnets, traffic sales, source code writing services, email/SMS spam and flooding services are available on the Chinese black markets.

Despite government censorship, a small number of Chinese cybercriminals still use dark web marketplaces to offer their services and products. Those marketplaces are typically specialized in the commercialization of stolen personally identifiable information (PII), bank accounts with high balances, hacking services, and malware customization. However, these darknet markets or hacking forums are not easily accessible because the Chinese government blocks the Tor anonymity network. A large number of Chinese cybercriminals continue to use exclusive and opaque QQ groups, Weibo fora and Baidu Teiba for advertising and communication. Chinese cybercriminals are also active on the clearnet. To avoid government censors and crackdowns, Chinese cybercriminals extensively use slang or other linguistic tactics for communication and advertising, which can be difficult for outsiders to comprehend. For instance, Chinese cybercriminals call a compromised computer or server “chicken meat.” Stolen bank accounts, credit card passwords, or other hijacked accounts are referred to as either “letters” or “envelopes.” Malicious websites and email accounts used for credential phishing attacks or spamming are referred to as “boxes.” Stolen information or details stored in the back of the magnetic stripe of a bank card are referred to as “data”, “track material” or simply “material.”

Moving Operational Base Abroad

Another noticeable trend is that an increasing number of Chinese cybercriminal gangs are moving their operational base abroad, using cryptocurrencies to launder money. They appear to prefer countries and jurisdictions with weak cybercrime legislation or weak enforcement, such as Malaysia, Indonesia, Cambodia and the Philippines. Since 2017, China’s Ministry of Public Security has uncovered over5,000 cases of cross-border telecommunication fraud involving more than US $150 million. Some of the cybercriminal groups are highly structured and work as traditional mafia-like groups that engage delinquent IT professionals; some Chinese cybercrime gangs are well-structured with clear divisions of labor and multiple supply chains. Members are typically located in close geographic proximity, even when the attacks are transnational.

Unique Culture and Practices

Chinese hackers employ different payment methods, recruiting strategies, and operating structures from other cybercriminal undergrounds. AliPay and bank transfers are the generally accepted payment methods advertised by Chinese-language hacking forums; many other forums typically prefer Monero and Bitcoin.

The “Master-Apprentice Mechanism,” which is a form of mentorship, plays a significant role in the Chinese hacking communities. Many Chinese hacker groups utilize the strategy to recruit new members or make profits. As shown in the following graph, QQ hacking group masters, usually masterminds of an organized crime group or an administrator of a hacking community, collect training fees from the members they recruit. These members, known as “apprentices” or “hackers-in-training” are required to participate in multiple criminal “missions” before they complete the training programs. Once training is complete, they are eligible to upgrade to full-time hackers working for their masters and responsible for downstream operations, such as targeted attacks, website hacking and database exfiltration.

Growth of Chinese Cybercrime

The Chinese cybercriminal underground has gone through drastic changes over the years. It gradually transformed from small local networks, targeting mostly Chinese businesses or citizens, to larger and well-organized criminal groups capable of hacking international organizations. My research indicates that there has been a growing threat activity targeting individuals and organizations in South Korea, Taiwan, Singapore, Germany, Canada and the United States. Chinese cybercriminals offer a wide variety of goods and services, ranging from physical counterfeit of US and Canadian driver’s licenses, scans of counterfeit US and Canadian driver’s licenses, US cell phone numbers, credit cards and identification cards to stolen social media and email accounts.

As shown in the following screenshots, 1 million stolen US emails accounts with encrypted passwords are selling for US $117; 1.9 million stolen German email accounts with clear text passwords are available on the Chinese black market for US $400. Counterfeit or scans of US or Canadian passports or drivers licenses are also for sale for as little as US $13.

As shown in the following screenshot, Chinese hackers are also selling stolen personal data, including identification cards and passports from Taiwan and South Korean citizens.

Login credentials for banks around the world are available on the Chinese cybercriminal underground market, and the higher the available balance of an account, the higher its selling price. Packages of hacked accounts from major US social media companies and networking platforms, gaming service providers, as well as media service providers are sold for as little as US $29 in the underground cybercrime market. These social media accounts are sometimes hacked with the intention of using them as a way to generate fake accounts to ensnare even more web users. A large number of email accounts from Taiwanese (i.e., @yahoo.com.tw) and South Korean email service providers (i.e., @nate.com, @yahoo.com.kr) are being sold on the Chinese black market.

Increasingly Difficult to Separate Cybercrime From Cyberespionage Activity

As the Chinese cybercriminal underground quickly expands its scope and sophistication, it is increasingly difficult to separate cybercrime from cyber espionage activity. This is especially true as I observe that Chinese cybercriminals offer services to spy on businesses and sell commodities that can be used to target businesses or government officials for economic and political espionage purposes. One of the most interesting items I found for sale in the Chinese cybercriminal underground is a full business dossier on Chinese companies and government agencies. Some Chinese hackers sell internal employee directories from high-profile technology companies. Chinese cybercriminals appear to work with malicious insiders or hire hackers to work as undercover agents inside of telecommunications service providers, financial services and technology companies to steal company secrets or other proprietary information. Documents include detailed contact information of CEOs and senior management from China’s top 50 companies. Other business proprietary information, such as credentials associated with a company’s various bank accounts, funding history, marketing strategies, and Tax Identification Number (TIN) are also available for sale on the black market. Malicious actors can use the above-mentioned information to launch targeted attacks against a business or leverage third-party vulnerabilities, such as trusted financial services, staffing firms and IT service providers to infiltrate a target system.

Conclusion

China’s cybercrime networks are rapidly growing in scope and sophistication. Compared to my earlier research paper on China’s cybercriminal underground from three years ago, Chinese cybercriminals have begun to embrace a sophisticated business-model approach and develop complex hierarchies, partnerships and collaboration with cybercriminal groups at home and internationally. These globally operating and organized cybercrime networks are basing themselves in countries with weak legal systems and law enforcement, while taking full advantage of global Internet connectivity to attack targets worldwide. A growing number of Chinese cybercriminals from these networks leverage the deep web to host their infrastructure and sell illegal goods and services, instead of relying on traditional peer-to-peer engagement through the QQ platform. To accelerate profitability, the Chinese hacking community has adopted tactics and techniques similar to Russian and other prominent cybercriminal underground markets to become more structured and service-oriented. In contrast, the Russian cybercriminal networks have been known for their multi-faceted criminal organizational structure specialized in monetizing PII theft and financial fraud. Yet, China’s cybecriminal underground, on the other hand, has placed greater emphasis on community and discipleship in achieving financial gains. Many of China’s cybercriminal networks incorporate this discipleship, also known as the “master-apprentice mechanism”, into a recruiting strategy that is largely different from their Russian counterparts. As China’s cybercrime continues to evolve and advance, international organizations operating in the Asia Pacific region are facing an expanding threat landscape from cybercriminal activity targeting high-value business assets. Intellectual property and identity theft can also cause substantial economic consequences.

The post How Chinese Cybercriminals Use Business Playbook to Revamp Underground appeared first on McAfee Blog.

Today McAfee released the results of a survey of county websites and county election administration websites in the 13 states projected as battleground states in the 2020 U.S. presidential elections. We found that significant majorities of these websites lacked the official government .GOV website validation and HTTPS website security measures to prevent malicious actors from launching copycat web domains posing as legitimate county government sites.

These shortcomings could make it possible for malicious actors to spread false and misleading election information through mass bulk email and website promotion campaigns that could suppress, misdirect, or otherwise disrupt Election Day proceedings in such a way that they could impact the number of votes cast and, ultimately, perhaps impact the results of the 2020 U.S. elections.

Why .GOV & HTTPS?

Whereas websites using .COM, .NET, .ORG, and .US in their names are easily accessible to anyone with a credit card from website domain vendors such as GoDaddy.com, acquiring a .GOV website name requires that buyers submit evidence to the U.S. government that they truly are buying these names on behalf of legitimate local, county, or state government entities.

The lack of .gov in a website name means that no controlling government authority has validated that the website in question is legitimate.

When website visitors see the HTTPS and a lock icon in the address of a website they are visiting, this means that their browser has made a secure connection with that website through a technology called Secure Sockets Layer (SSL). While SSL sounds technical, the security it delivers is easy to understand. These signifiers simply tell visitors that any personal voter registration information that they share with those websites is encrypted and cannot be intercepted and stolen by hackers while they are visiting the site.

 

Additionally, and more importantly to the election disinformation issue, they also tell visitors that they cannot be re-routed against their will from legitimate government websites to other websites pretending to be government websites.

What McAfee’s survey found

McAfee’s January 2020 survey researched states projected by U.S. election prognosticators to be pivotal in determining the victor in the 2020 Presidential Elections. States surveyed include Arizona, Florida, Georgia, Iowa, Michigan, Minnesota, Nevada, New Hampshire, North Carolina, Ohio, Pennsylvania, Texas, and Wisconsin. Together, these states account for 201 of the 270 electoral votes required to win the U.S. presidential election.

State counties lacking .GOV validation

Of the 1,117 counties in the survey group, 83.3% of their websites lack .GOV validation. Minnesota ranked the lowest among the surveyed states in terms of .GOV website validation with 95.4% of counties lacking U.S. government certification. Other states severely lacking in .GOV coverage included Texas (94.9%), New Hampshire (90.0%), Michigan (89.2%), Iowa (88.9%), Nevada (87.5%), and Pennsylvania (83.6%).

Arizona had the highest percentage of main county websites validated by .GOV with 66.7% coverage, but even this percentage suggests that a third of the Grand Canyon State’s county websites are unvalidated and that hundreds of thousands of voters could still be subjected to disinformation schemes.

State counties lacking HTTPS protection

McAfee’s survey found that 46.6% of county websites lack HTTPS encryption. Texas ranked the lowest in terms of encryption with 77.2% of its county websites failing to protect citizens visiting these web properties. Other states with counties lacking in encryption included Pennsylvania (46.3%), Minnesota (42.5%), and Georgia (38.4%).

Assessment of Iowa and New Hampshire

In Iowa, 88.9% of county websites lack .GOV validation, and as many as 29.3% lack HTTPS encryption. Ninety percent of New Hampshire’s county websites lack .GOV validation, and as many as 30% of the Granite State’s counties lack encryption.

Inconsistent naming standards

McAfee’s research found that some states attempted to establish standard naming standards, such as www.co.[county name].[two-letter state abbreviation].us. Unfortunately, these formats were followed so inconsistently that a voter seeking election information from her county website cannot be confident that a web domain following such a standard is indeed a legitimate site.

Easy-to-remember naming formats

McAfee found 103 cases in which counties set up easy-to-remember, user-friendly domain names to make their election information easier to remember and access for the broadest possible audience of citizens. Examples include www.votedenton.com, www.votestanlycounty.com, www.carrollcountyohioelections.gov, www.voteseminole.org, and www.worthelections.com. While 93 of these counties (90.2%) protected voters visiting these sites with encryption, only two validated these special domains and websites with .GOV. This suggests that malicious parties could easily set up numerous websites with similarly named domains to spoof these legitimate sites.

.GOV and elections

The lack of .gov matters because, without an official government body validating whether websites truly belong to the government entities they claim, it’s possible for malicious actors to spoof legitimate government sites with fraudulent websites.

If a malicious foreign actor can spoof government websites, he can send hundreds of thousands of emails to voters and use both those emails and the websites to which they are tied to send voters information on the wrong polling places, phony voter registration processes or requirements (barriers), or other incorrect voting instructions that could suppress, misdirect, or otherwise disrupt a key county’s electorate from voting.

If the malicious actor can launch such a digital disinformation campaign close enough to election day, he could reach a critical mass of voters. If he does so before county and state officials become aware of the campaign, it could be very difficult for the officials to counter the disinformation before voter behavior is impacted.

If the actor can successfully disrupt the voting behavior of just tens of thousands of citizens in these key states, their votes may not be counted or their confidence in the validity of election results and even legitimacy of the democratic process overall could be badly shaken.

Ultimately, if a malicious actor seeks to undermine confidence in America’s system of government, such a digital disinformation campaign can succeed in damaging confidence in the electoral process, even if he cannot succeed in impacting actual votes.

Ohio’s Strategy for transitioning to .GOV

While only 19.3% of Ohio’s 88 county main websites have .GOV validation, the state leads McAfee’s survey with 76.1% of county election websites and webpages validated by .GOV certification.

This leadership position appears to be the result of a state-led initiative to transition county election-related content to .GOV validated web properties. A majority of counties have subsequently transitioned their main county websites to .GOV domains, their election-specific websites to .GOV domains, or their election-specific webpages to Ohio’s own .GOV-validated https://ohio.gov/ domain (i.e. https://www.boe.ohio.gov/vanwert/). See here for a complete list of Ohio county election websites.

Such a .GOV transition strategy constitutes an interim solution until more comprehensive efforts are made at the state and federal government level through initiatives such as The DOTGOV Act of 2020. This legislation would require the Department of Homeland Security (DHS) to support .GOV adoption for local governments with technical guidance and financial support.

Please see the following for more information on this subject:

• McAfee 2020 Election Voter Info Webpage
• The DOTGOV Act of 2020 Blog

 

 

 

The post U.S. Battleground County Website Security Survey appeared first on McAfee Blog.

There has been a dramatic shift in the platforms targeted by attackers over the past few years. Up until 2016, browsers tended to be the most common attack vector to exploit and infect machines but now Microsoft Office applications are preferred, according to a report published here during March 2019. Increasing use of Microsoft Office as a popular exploitation target poses an interesting security challenge. Apparently, weaponized documents in email attachments are a top infection vector.

Object Linking and Embedding (OLE), a technology based on Component Object Model (COM), is one of the features in Microsoft Office documents which allows the objects created in other Windows applications to be linked or embedded into documents, thereby creating a compound document structure and providing a richer user experience. OLE has been massively abused by attackers over the past few years in a variety of ways. OLE exploits in the recent past have been observed either loading COM objects to orchestrate and control the process memory, take advantage of the parsing vulnerabilities of the COM objects, hide malicious code or connecting to external resources to download additional malware.

Microsoft Rich Text Format is heavily used in the email attachments in phishing attacks. It has been gaining massive popularity and its wide adoption in phishing attacks is primarily attributed to the fact that it has an ability to contain a wide variety of exploits and can be used efficiently as a delivery mechanism to target victims. Microsoft RTF files can embed various forms of object types either to exploit the parsing vulnerabilities or to aid further exploitation. The Object Linking and Embedding feature in Rich Text Format files is largely abused to either link the RTF document to external malicious code or to embed other file format exploits within itself and use it as the exploit container. Apparently, the RTF file format is very versatile.

In the below sections, we attempt to outline some of the exploitation and infection strategies used in Microsoft Rich Text format files over the recent past and then towards the end , we introspect on the key takeaways that can help automate the analysis of RTF exploits and set the direction for the generic analysis approach.

RTF Control Words

Rich Text Format files are heavily formatted using control words. Control words in the RTF files primarily define the way the document is presented to the user. Since these RTF control words have the associated parameters and data, parsing errors for them can become a target for exploitation. Exploits in the past have been found using control words to embed malicious resources as well. Consequently, it becomes significant to examine a destination control word that consumes data and extract the stream. RTF specifications describe several hundred control words consuming data.

RTF parsers must also be able to handle the control word obfuscation mechanisms commonly used by attackers, to further aid the analysis process. Below is one of the previous instances’ exploits using control word parameters to introduce executable payloads inside the datastore control word.

Overlay Data in RTF Files

Overlay data is the additional data which is appended to the end of RTF documents and is predominantly used by exploit authors to embed decoy files or additional resources, either in the clear, or encrypted form which is usually decrypted when the attacker-controlled code is executed. Overlay data of the volume beyond a certain size should be deemed suspicious and must be extracted and analysed further. However, Microsoft Word RTF parser will ignore the overlay data while processing RTF documents. Below are some instances of RTF exploits with a higher volume of overlay data appended at the end of the file, with CVE-2015-1641 embedding both the decoy document and multi-staged shellcodes with markers.

Object Linking and Embedding in RTF Files

Linked or embedded objects in RTF documents are represented as RTF objects, precisely to the RTF destination control word “object”. The data for the embedded or linked object is stored as the parameter to the RTF sub-destination control word “objdata” in the hex-encoded OLESaveToStream format. Modifier control word “objclass” determines the type of the object embedded in the RTF files and helps the client application to render the object. However, the hex encoded object data as the argument to the “objdata” control word can also be heavily obfuscated, either to make the reverse engineering and analysis effort more time consuming or to break the immature RTF parsers. Apparently, OLE has been one of the dominant attack vectors in the recent past, with many instances of OLE based exploits used in targeted attacks, essentially implying robust RTF document parsers for the extraction of objects, along with deeper inspection of object data is extremely critical.

Object Linking – Linking RTF to External Resource

Using object linking, it is possible to link the RTF files to the remote object which could be the link to the malicious resource hosted on the remote server. This leads the resulting RTF file to behave as a downloader and subsequently execute the downloaded resource by invoking the registered application-specific resource handlers. Inspecting the modifier RTF control words to “object”, linked objects are indicated by another nested control word “objautlink”, as represented below in the RTF document.

As indicated in the above representation, object data as the argument to the RTF control word “objdata” is OLE1.0NativeStream in the OLESaveToStream format which is followed by the NativeDataSize indicating the size of the OLE2.0 Compound document that is wrapped in the NativeStream. As per the Rich Text Format specifications, if the object is linked to the container application, which in this case is the RTF document, the Root Storage directory entry of the compound document will have the CLSID of the StdOleLink indicating the linked object. Also, when the object is in the OLE2.0 format, the linked source data is specified in the MonikerStream of the OLESteam structure. As highlighted below, while parsing the object data, the ole32.OleConvertOLESTREAMToIStorage function is responsible for converting the OLE1.0 NativeStream data to OLE2.0 structured storage format. Following the pointer to the OLE stream lpolestream will allow us to visualize the parsed extracted native data. Below is a memory snapshot from when an RTF document with a linked object was parsed by the winword.exe process.

Launching the RTF document with the link to external object will throw up a dialogue box asking to update the data from the linked object, as shown below.

However, this is not the ideal exploitation strategy to target victims. This error can be eliminated by inserting another modifier control word “objupdate”, which internally calls link object’s IOleObject::Update method to update the link’s source.

Subsequently the urlmon.dll, which is the registered server for the URL Moniker, is instantiated.

Once the COM object is instantiated, the connection is initiated to the external resource and, based on the content-type header returned by the server in the response, URL Moniker consults the Mime database in the registry and invokes registered application handlers.

Details on how URL Moniker is executed and an algorithm to determine which appropriate handlers to invoke is described by Microsoft here.  We have had multiple such RTF exploits in the past including CVE-2017-0199, CVE-2017-8756 and others using Monikers to download and execute remote code.

However, COM objects used in the mentioned exploits had been blacklisted by Microsoft in the newer versions, but similar techniques could be used in future which essentially necessitates the analysis of OLE structured storage streams.

Object Embedding – RTF Containing OLE Controls

As indicated earlier, embedded objects are represented in the container documents in the OLE2 format. When the object is stored in the OLE2 format, the container application (here Rich Text Format files) creates the OLE Compound File Storage for each of the objects embedded and the respective object data is stored in the OLE Compound File Stream Objects. Layout of the container documents storing embedded objects is as represented below and described in the Microsoft documentation here.

RTF exploits historically have been found embedding and loading multiple OLE controls in order to bypass exploit mitigations and to take advantage of memory corruption vulnerabilities by loading vulnerable OLE controls. Embedded OLE controls in the RTF document are usually indicated by nested control word “objocx” or “objemb” followed by the “objclass” with the argument as the name of the OLE control to render the object. Below is one of the examples of the previous exploit used in the targeted attacks, which exploited a vulnerability in the COM object and loaded another OLE control to aid the exploitation process which had the staged malicious code embedded. Apparently, it is critical to extract this object data, extract the OLE2 compound file storage and extract each of the stream objects for further inspection of hidden malicious shellcodes.

Object Embedding – RTF Containing Other Documents

Malicious RTF documents can use the OLE functionality to embed other file formats like Flash files and Word documents, either to exploit respective file format vulnerabilities or to further assist and set up the stage for the successful exploitation process. Multiple RTF exploits have been observed in the past embedding OOXML documents using OLE functionality to manipulate the process heap memory and bypass Windows exploit mitigations. In RTF files, embedded objects are usually indicated by nested control word “objemb” with a version-dependent “ProgID” string as the argument to the nested control word “objclass”. One such RTF exploit used in targeted attacks in the recent past, is as indicated below.

Below is another instance where the PDF file was physically embedded within the compound document. As mentioned, the embedded object is stored physically along with all the information required to render it.

In the embedded object, the creating application’s identifier is stored in the CLSID field of the compound file directory entry of the CFB storage object. If we take a look at the previous instance, when the object data is extracted and inspected manually, the following CLSID is observed in the CFB storage object, which corresponds to the CLSID_Microsoft_Word_Document.

When OLE2 stream objects are parsed and the embedded OOXML is extracted and analysed after deflating the contents, we see the suspicious ActiveX object loading activity and embedded malicious code in one of the binary files. Apparently, it is significant to extract the embedded files in RTF and perform further analysis.

OLE Packages in RTF Files

RTF documents can also embed other file types like scripts (VBSsript, JavaScript, etc.), XML files and executables via OLE packages. An OLE package in an RTF file is indicated by the ProgID string “package” as the argument to the nested control word “objclass”. Packager format is the legacy format that does not have an associated OLE server. Looking at the associated CLSID in the registry, there is no specific data format mapped with Packages.

This essentially implies that OLE packages can store multiple file types and, if a user clicks the object, it will lead to execution of it and, eventually, infection of the machine if they are malicious scripts. RTF documents have been known to deliver malware by embedding scripts via OLE packages and then using Monikers, as described in the previous sections, to drop files in the desired directory and then execute them. One such instance of a malicious RTF document exploiting CVE-2018-0802, embedding an executable file, is shown below.

Since many RTF documents have been found delivering malware via OLE packages, it is critical to look for these embedded objects and analyse them for such additional payloads. Embedded executables / scripts within RTF could be malicious. Looking for OLE packages and extracting embedded files should be a trivial task.

The above exploit delivery strategies can allow us to take a step towards building analysis frameworks for RTF documents. Primarily, inspecting the linked or embedded objects turns out to be the critical aspect of automated analysis tasks along with the RTF control words inspection. The following are the key takeaways:

• Using the RTF file as the container, many other file format exploits can be embedded inside using the Object Linking and Embedding feature, essentially weaponizing the RTF documents.
• Extract and analysing embedded or linked objects for malicious code, payload or resource handler invocations becomes very essential.
• If RTF document has a higher volume of appended data, it must be further looked at.
• Non-OLE control words and OLE packages must also be analysed for any malicious content.

McAfee Response

As Microsoft Office vulnerabilities continue to surface, generic inspection methods will have to be improved and enhanced, consequently leading to better detection results. As a reminder, the McAfee Anti-Malware engine used on all our endpoints and most of our appliances has the potential to unpack Office, RTF and OLE documents, expose the streams of content and unpack these streams if necessary.

The post An Inside Look into Microsoft Rich Text Format and OLE Exploits appeared first on McAfee Blog.

Enterprise customers looking for information on defending against Curveball can find information here.

2020 came in with a bang this year, and it wasn’t from the record-setting number of fireworks on display around the world to celebrate the new year. Instead, just over two weeks into the decade, the security world was rocked by a fix for CVE-2020-0601 introduced in Microsoft’s first patch Tuesday of the year. The bug was submitted by the National Security Administration (NSA) to Microsoft, and though initially deemed as only “important”, it didn’t take long for everyone to figure out this bug fundamentally undermines the entire concept of trust that we rely on to secure web sites and validate files. The vulnerability relies on ECC (Elliptic Curve Cryptography), which is a very common method of digitally signing certificates, including both those embedded in files as well as those used to secure web pages. It represents a mathematical combination of values that produce a public and private key for trusted exchange of information. Ignoring the intimate details for now, ECC allows us to validate that files we open or web pages we visit have been signed by a well-known and trusted authority. If that trust is broken, malicious actors can “fake” signed files and web sites and make them look to the average person as if they were still trusted or legitimately signed. The flaw lies in the Microsoft library crypt32.dll, which has two vulnerable functions. The bug is straightforward in that these functions only validate the encrypted public key value, and NOT the parameters of the ECC curve itself. What this means is that if an attacker can find the right mathematical combination of private key and the corresponding curve, they can generate the identical public key value as the trusted certificate authority, whomever that is. And since this is the only value checked by the vulnerable functions, the “malicious” or invalid parameters will be ignored, and the certificate will pass the trust check.

As soon as we caught wind of the flaw, McAfee’s Advanced Threat Research team set out to create a working proof-of-concept (PoC) that would allow us to trigger the bug, and ultimately create protections across a wide range of our products to secure our customers. We were able to accomplish this in a matter of hours, and within a day or two there were the first signs of public PoCs as the vulnerability became better understood and researchers discovered the relative ease of exploitation.

Let’s pause for a moment to celebrate the fact that (conspiracy theories aside) government and private sector came together to report, patch and publicly disclose a vulnerability before it was exploited in the wild. We also want to call out Microsoft’s Active Protections Program, which provided some basic details on the vulnerability allowing cyber security practitioners to get a bit of a head start on analysis.

The following provides some basic technical detail and timeline of the work we did to analyze, reverse engineer and develop working exploits for the bug.  This blog focuses primarily on the research efforts behind file signing certificates.  For a more in-depth analysis of the web vector, please see this post.

Creating the proof-of-concept

The starting point for simulating an attack was to have a clear understanding of where the problem was. An attacker could forge an ECC root certificate with the same public key as a Microsoft ECC Root CA, such as the ECC Product Root Certificate Authority 2018, but with different “parameters”, and it would still be recognized as a trusted Microsoft CA. The API would use the public key to identify the certificate but fail to verify that the parameters provided matched the ones that should go with the trusted public key.

There have been many instances of cryptography attacks that leveraged failure of an API to validate parameters (such as these two) and attackers exploiting this type of vulnerability. Hearing about invalid parameters should raise a red flag immediately.

To minimize effort, an important initial step is to find the right level of abstraction and details we need to care about. Minimal details on the bug refer to public key and curve parameters and nothing about specific signature details, so likely reading about how to generate public/private key in Elliptical Curve (EC) cryptography and how to define a curve should be enough.

The first part of this Wikipedia article defines most of what we need to know. There’s a point G that’s on the curve and is used to generate another point. To create a pair of public/private keys, we take a random number k (the private key) and multiply it by G to get the public key (Q). So, we have Q = k*G. How this works doesn’t really matter for this purpose, so long as the scalar multiplication behaves as we’d expect. The idea here is that knowing Q and G, it’s hard to recover k, but knowing k and G, it’s very easy to compute Q.

Rephrasing this in the perspective of the bug, we want to find a new k’ (a new private key) with different parameters (a new curve, or maybe a new G) so that the ECC math gives the same Q back. The easiest solution is to consider a new generator G’ that is equal to our target public key (G’= Q). This way, with k’=1 (a private key equal to 1) we get k’G’ = Q which would satisfy the constraints (finding a new private key and keeping the same public key).

The next step is to verify if we can actually specify a custom G’ while specifying the curve we want to use. Microsoft’s documentation is not especially clear about these details, but OpenSSL, one of the most common cryptography libraries, has a page describing how to generate EC key pairs and certificates. The following command shows the standard parameters of the P384 curve, the one used by the Microsoft ECC Root CA.

Elliptic Curve Parameter Values

We can see that one of the parameters is the Generator, so it seems possible to modify it.

Now we need to create a new key pair with explicit parameters (so all the parameters are contained in the key file, rather than just embedding the standard name of the curve) and modify them following our hypothesis. We replace the Generator G’ by the Q from Microsoft Certificate, we replace the private key k’ by 1 and lastly, we replace the public key Q’ of the certificate we just generated by the Q of the Microsoft certificate.

To make sure our modification is functional, and the modified key is a valid one, we use OpenSSL to sign a text file and successfully verify its signature.

Signing a text file and verifying the signature using the modified key pair (k’=1, G’=Q, Q’=Q)

From there, we followed a couple of tutorials to create a signing certificate using OpenSSL and signed custom binaries with signtool. Eventually we’re greeted with a signed executable that appeared to be signed with a valid certificate!

Spoofed/Forged Certificate Seemingly Signed by Microsoft ECC Root CA

Using Sysinternal’s SigChecker64.exe along with Rohitab’s API Monitor (which, ironically is on a site not using HTTPS) on an unpatched system with our PoC, we can clearly see the vulnerability in action by the return values of these functions.

Rohitab API Monitor – API Calls for Certificate Verification

Industry-wide vulnerabilities seem to be gaining critical mass and increasing visibility even to non-technical users. And, for once, the “cute” name for the vulnerability showed up relatively late in the process. Visibility is critical to progress, and an understanding and healthy respect for the potential impact are key factors in whether businesses and individuals quickly apply patches and dramatically reduce the threat vector. This is even more essential with a bug that is so easy to exploit, and likely to have an immediate exploitation impact in the wild.

McAfee Response

McAfee aggressively developed updates across its entire product lines.  Specific details can be found here.

 

The post CurveBall – An Unimaginative Pun but a Devastating Bug appeared first on McAfee Blog.