Avzhan DDoS bot dropped by Chinese drive-by attack

The Avzhan DDoS bot has been known since 2010, but recently we saw it in wild again, being dropped by a Chinese drive-by attack. In this post, we’ll take a deep dive into its functionality and compare the sample we captured with the one described in the past.

Analyzed sample

Behavioral analysis

Installation

After being deployed, the malware copies itself under a random name into a system folder, and then deletes the original sample:

Its way to achieve persistence is by registering itself as a Windows Service. Of course, this operation requires administrator rights, which means for successful installation, the sample must run elevated. There are no UAC bypass capabilities inside the bot, so it can only rely on some external droppers, using exploits or social engineering.

Example of added registry keys, related to registering a new service:

We find it also on the list of the installed services:

Network traffic

We can see that the bot connects to its CnC:

Looking at the network traffic, we see the beacon that is sent. It is in a binary format and contains information collected about the victim system:

The beacon is very similar to the one described in 2010 by Arbor Networks here. The server responds with a single NULL byte.

Apart from this, we also see traffic generated probably by DGA:

The bot queries repetitively for addresses in format 6{a-z}.com.

During the experiments, we didn’t capture traffic related to the typical DDoS activities performed by this bot. However, we can see such capabilities clearly in the code.

Inside the sample

Stage 1: the loader

The sample is distributed in a packed form. The main sample’s original name is Cache.dat, and it exports one function: Ip.

Looking inside the Ip, we can easily read that it creates a variable, fills it with strings, and then returns it:

Those are the same parameters that we observed during the behavioral analysis. For example, we can see that the service name is “Nationalscm” and the referenced server, probably CnC is: wm.shiquanxian.cn:8080 (that resolves to: 103.85.226.65:8080). So, this is likely the function responsible for filling those parameters and passing them further.

The main function of this executable is obfuscated, and the flow of the code is hard to follow—it consists of small chunks of code connected by jumps, in between of which junk instructions are added:

However, just below the function Ip, we see another one that looks readable:

Looking at its features, we see that it is a good candidate for a function that actually unpacks and installs the payload in the following process:

  1. It takes some hardcoded buffer and processes it—that looks like de-obfuscating the payload.
  2. It searches a function “StartupService” in the export table of the unpacked payload—it gives us hint that the unpacked content is a PE file.
  3. Finally, it calls the found function within the payload.

We can confirm this by observing the execution under the debugger. After the decoding function was called, we see that indeed the buffer becomes a new PE file:

At this moment, we can dump the buffer, trim it, and analyze it separately. It turns out that this is the core of the bot, performing all of the malicious operations. The PE file is in the raw format, so no unmapping is needed. Further, the loader will allocate another area of memory and map there the payload into the Virtual Format so that it can be executed.

Anti-dumping tricks

This malware uses few tricks to evade automated dumpers. First of all, the payload that is loaded is not aligned to the beginning of the page:

If we dump it at this moment, we would also need to unmap it (i.e. by pe_unmapper) because this time it is in the Virtual Format. However, there are some unpleasant surprises: The relocation table and resources have been removed after use by the loader. This is why it is usually more reliable to dump the payload before it is mapped. However, some of the data inside the payload may be also filled on load. So if we don’t dump both versions, we may possibly miss some information.

In the version from 2010, the outer layer is missing. The malware is distributed via a single executable that is an equivalent of the payload unpacked from the current sample.

Stage 2: the core

By following the aforementioned steps, we obtain the core DLL, named Server.dll. We find that the core is pretty old—this hash was seen for the first time on VirusTotal more than a year ago. However, it was not described in detail at that time, so I think it is still worth analyzing.

The sample from 2010, in contrast, is not a DLL but a standalone EXE. Yet, looking at the strings and comparing both with the help of BinDiff, we can see striking similarities that prove that the core didn’t evolve much.

Execution flow

The execution starts in the exported function: StartupServer. At the beginning, the sample calls OutputDebugStringA with non-ascii content. What’s interesting is that the content is not random. The same bytes were used previously in the loader, just before executing the function within the payload. Yet, its purpose remains unknown.

It also tries to check if the current DLL has been loaded by the main module that exports a function “Ip.” If it is so, it calls it:

As we remember, the function with exactly this name was exported by the outer layer. It was supposed to retrieve the configuration of the bot, such as the CnC address and Windows Service name. After being retrieved, the data gets copied into the bot’s data section (the configuration gets hardcoded into the bot).

After that, the malware proceeds with its main functionality. We can see that the data that got retrieved and hardcoded is later being passed to the function installing the service:

Based on the presence of the corresponding registry keys, the malware distinguishes if this is its first run or if it had already been installed. Depending on this information, it can take alternative paths.

If the malware was not installed yet, it proceeds with the installation and exits afterward:

Otherwise, it runs its main service function:

The main service function is responsible for communication with the CnC. It deploys a thread that reads commands and deploys appropriate actions:

Functionality

First the bot connects to the CnC and sends a beacon containing information gathered about the victim system:

The information gathered is detailed, containing processor features as well as the Internet speed. We saw this data being sent during the behavioral analysis.

After the successful beaconing, it deploys the main loop, where is listens for the commands from the CnC, parses them, and executes:

As we can see, the malware can act as a downloader—it can fetch and deploy a new executable from the link supplied by the CnC:

The CnC can also push an update of the main bot, as well as instruct the bot to fully remove itself.

But the most important capabilities lie in few different DDoS attacks that can be deployed remotely on any given target. The target address, as well as the attack ID, are supplied by the CnC.

Among the requests that are prepared for the attacks, we can see the familiar strings, whose purpose was already described in the report from 2010. We can see the malformed GET request:

As an alternative, it may use one of the valid GET requests, for example:

The flooding function is deployed in a new thread, and repeats the requests in a loop until the stop condition is enabled. Example:

Conclusion

This bot is pretty simple, prepared by an unsophisticated actor. Featurewise, it hasn’t changed much over years. The only additions were intended to obfuscate the malware and give an ability to add the configuration by the outer layer.

The post Avzhan DDoS bot dropped by Chinese drive-by attack appeared first on Malwarebytes Labs.

Go to Source
Author: hasherezade

Drive-by cryptomining campaign targets millions of Android users

Malvertising and online fraud through forced redirects and Trojanized apps—to cite the two most common examples—are increasingly plaguing Android users. In many cases, this is made worse by the fact that people often don’t use web filtering or security applications on their mobile devices.

A particular group is seizing this opportunity to deliver one of the most lucrative payloads at the moment: drive-by cryptomining for the Monero (XMR) currency. In a campaign we first observed in late January, but which appears to have started at least around November 2017, millions of mobile users (we believe Android devices are targeted) have been redirected to a specifically designed page performing in-browser cryptomining.

In our previous research on drive-by mining, we defined this technique as automated, without user consent, and mostly silent (apart from the noise coming out of the victim’s computer fan when their CPU is clocked at 100 percent). Here, however, visitors are presented with a CAPTCHA to solve in order to prove that they aren’t bots, but rather real humans.

“Your device is showing suspicious surfing behaviour. Please prove that you are human by solving the captcha.”

Until the code (w3FaSO5R) is entered and you press the Continue button, your phone or tablet will be mining Monero at full speed, maxing out the device’s processor.

Redirection mechanism

The discovery came while we were investigating a separate malware campaign dubbed EITest in late January. We were testing various malvertising chains that often lead to tech support scams with an Internet Explorer or Chrome user-agent on Windows. However, when we switched to an Android, we were redirected via a series of hops to that cryptomining page.

It seems odd that a static code (which is also hardcoded in the page’s source) would efficiently validate traffic between human and bot. Similarly, upon clicking the Continue button, users are redirected to the Google home page, another odd choice for having proved you were not a robot.

While Android users may be redirected from regular browsing, we believe that infected apps containing ad modules are loading similar chains leading to this cryptomining page. This is unfortunately common in the Android ecosystem, especially with so-called “free” apps.

It’s possible that this particular campaign is going after low quality traffic—but not necessarily bots —and rather than serving typical ads that might be wasted, they chose to make a profit using a browser-based Monero miner.

We identified several identical domains all using the same CAPTCHA code, and yet having different Coinhive site keys (see our indicators of compromise for the full details). The first one was registered in late November 2017, and new domains have been created since then, always with the same template.

Domain name, registration date

Traffic stats

We believe there are several more domains than just the few that we caught, but even this small subset is enough to give us an idea of the scope behind this campaign. We shared two of the most active sites with ad fraud researcher Dr. Augustine Fou, who ran some stats via the SimilarWeb web analytics service. This confirmed our suspicions that the majority of traffic came via mobile and spiked in January.

We estimate that the traffic combined from the five domains we identified so far equals to about 800,000 visits per day, with an average time of four minutes spent on the mining page. To find out the number of hashes that would be produced, we could take a conservative hash rate of 10 h/s based on a benchmark of ARM processors.

It is difficult to determine how much Monero currency this operation is currently yielding without knowing how many other domains (and therefore total traffic) are out there. Because of the low hash rate and the limited time spent mining, we estimate this scheme is probably only netting a few thousand dollars each month. However, as cryptocurrencies continue to gain value, this amount could easily be multiplied a few times over.

Conclusion

The threat landscape has changed dramatically over the past few months, with many actors jumping on the cryptocurrency bandwagon. Malware-based miners, as well as their web-based counterparts, are booming and offering online criminals new revenue sources.

Forced cryptomining is now also affecting mobile phones and tablets en masse—not only via Trojanized apps, but also via redirects and pop-unders. We strongly advise users to run the same security tools they have on their PC on their mobile devices, because unwanted cryptomining is not only a nuisance but can also cause permanent damage.

Malwarebytes mobile users are protected against this threat.

Indicators of compromise

Domains:

rcyclmnr[].com
rcylpd[.]com
recycloped[.]com
rcyclmnrhgntry[.]com
rcyclmnrepv[.]com

Referring websites (please note that they should not be necessarily considered malicious):

panelsave[.]com
offerreality[.]com
thewise[.]com
go.bestmobiworld[.]com
questionfly[.]com
goldoffer[.]online
exdynsrv[.]com
thewhizmarketing[.]com
laserveradedomaina[.]com
thewhizproducts[.]com
smartoffer[.]site
formulawire[.]com
machieved[.]com
wtm.monitoringservice[.]co
traffic.tc-clicks[.]com
stonecalcom[.]com
nametraff[.]com
becanium[.]com
afflow.18-plus[.]net
serie-vostfr[.]com
pertholin[.]com
yrdrtzmsmt[.]com
yrdrtzmsmt.com
traffic.tc-clicks[.]com

Conhive site keys:

gufKH0i0u47VVmUMCga8oNnjRKi1EbxL
P3IN11cxuF4kf2kviM1a7MntCPu00WTG
zEqkQef50Irljpr1X3BqbHdGjMWnNyCd
rNYyUQUC5iQLdKafFS9Gi2jTVZKX8Vlq

The post Drive-by cryptomining campaign targets millions of Android users appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura

MedusaHTTP DDoS Slithers Back into the Spotlight

A view of medusaHTTP panel.

Executive Summary

MedusaHTTP is a HTTP-based DDoS botnet written in .NET, that surfaced in early 2017. MedusaHTTP is based off of MedusaIRC which leveraged IRC for its command and control communications instead of HTTP. MedusaIRC botnet has been advertised on various underground hacker marketplaces since 2015, while MedusaHTTP started appearing in 2017.

  • The alleged seller of MedusaIRC and MedusaHTTP, Stevenking(s) has advertised this botnet family on hacker marketplaces for many years.
  • MedusaHTTP has evolved from an IRC botnet to an HTTP botnet. The HTTP components appear to be reused code from the leaked Diamond Fox DDoS botnet.
  • MedusaHTTP was observed being distributed by the Rig Exploit Kit by an independent researcher.

 

Introduction

MedusaHTTP was discovered after reading an independent researcher’s blog post describing malware distributed by recent Rig exploit kit campaigns. Screenshots of network traffic from one of the malware payloads within the post, caught our attention:

MedusaHTTP .stop-all command

MedusaHTTP .httpstrong command

The blog post initially identified the payload responsible for this traffic as AZORult; however, the commands in this traffic suggest DDoS functionality. AZORult is classified as an information stealing trojan which has the primary objective of capturing passwords, financial and personal information from the victim’s system. Samples of this family and campaign objectives are not known to contain DDoS functionality, so this could suggest a major update to the AZORult malware. ASERT obtained the sample linked in the blog post from VirusTotal, and after analysis we believe this file is not AZORult but rather a new version of the DDoS bot known as Medusa.

 

Enter Medusa – StevenKings’ DDoS botnet kit since 2015

This isn’t the first time ASERT has encountered the Medusa botnet, we  previously analyzed the IRC version of Medusa in 2016. In addition, we found references of Medusa being advertised on underground hacker marketplaces dating back to 2015. Advertisements were posted by a user under the name of StevenKings, a sample image of an advertisement is provided below:

MedusaIRC advertisement from 2015

As insinuated above, Stevenkings may not be a native English speaker. We believe he or she may be a native Russian speaker based on the origin of their most active forum. In this 2015 advertisement, Stevenkings is selling the IRC version of Medusa for $500 in bitcoin, a cryptocurrency often leveraged in underground marketplaces. Reading further shows descriptions of future commands that will be added to the bot such as, “.httpstrong” which was the string that sparked our attention from the above researcher’s blog post. The advertisement also links to images of the botnet’s throughput, first showing screenshots to prove DDoS rates of 30k requests-per-second:

MedusaIRC 30k Request Per Second Proof

And then, a screenshot of it generating 3k requests-per-second with only 3 bots.

MedusaIRC 3k Requests Per Second with 3 Bots

Higher requests-per-second per bot allows a botnet controller to use less bots for taking down targets. This would mean the botnet controller could infect less victims while still remaining operationally successful.

 

Medusa Now in HTTP

Our research shows Stevenkings advertising the HTTP version of the Medusa botnet on underground hacker marketplaces in early 2017. The advertisements for this version included images of the HTTP command and control panel which appears to use the code and images from Diamond Fox, another well-known DDoS botnet.

A view of the MedusaHTTP admin panel.

A view of the MedusaHTTP attack page.

A view of the Diamond Fox admin panel for comparison.

Multiple versions of Diamond Fox botnet have been leaked over the past few years which would make the code reuse feasible for the Medusa malware author. All other portions of the code, except for the HTTP-based command and control communications, remain very similar to the IRC version of the Medusa botnet.

 

Command and Control Communication

The latest version of MedusaHTTP uses a HTTP-based command and control (C2) communication method as opposed the IRC communication of its predecessor. The initial connection uses a POST request with a static user agent of Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0 sent to the C2. In the POST request payload, the victim bot will send introspection information using a xyz form item. The format of the introspection information payload follows this format:

xyz=08:00:27:??:??:??|<OS Type>|Version

an example of this would be:

MedusaHTTP C2 Check-in

After the check-in command is sent, the C2 will either respond with a HTTP status code 200 as seen below:

MedusaHTTP C2 Status 200

or send back one of the following commands:

  • .icmp [host] [threads] [delay] [stoptime]
  • .httpseebix [www.website.com] [page.php] [threads] [delay] [stoptime]
  • .httpoverload [www.website.com] [page.php] [threads] [delay] [stoptime]
  • .httpstrong [www.website.com] [page.php] [threads] [delay] [stoptime]
  • .httpactive [www.website.com] [page.php] [threads] [delay] [stoptime]
  • .httpssl [www.website.com] [page.php] [threads] [delay] [true/false] [stoptime]
  • .proxy [www.website.com] [page.php] [webpagewithproxy] [threads] [delay] [stoptime]
  • .httppost [www.website.com] [page.php] [postcontent] [threads] [delay] [stoptime]
  • .smartflood [GET] [www.website.com] [page.php] [threads] [delay] [stoptime]
  • .smartflood [POST] [www.website.com] [page.php] [postcontent] [threads] [delay] [stoptime]
  • .syn [host] [port] [sockets] [threads]
  • .udp [host] [port] [sockets] [threads] [packetsize]
  • .download [http://website.com/exe.exe] [filename] [true/false]
  • .stop-[methodname]
  • .stop-all

After which the bot will either wait and check-in again at a later time or act on the specific command received.

 

Purported Capabilities

Stevenkings claims MedusaHTTP is capable of the following:

  • .httpssl is made for TLS and SSL websites. Using the TRUE option on httpssl will grab cookies.
  • .icmp is a layer 3 flood.
  • .httpseebix is ​​custom HTTP GET flood.
  • .httpstrong is a fast HTTP flood method.
  • .httpactive is a mix of TCP and layer 7.
  • .httpoverload can crash certain servers.
  • .httpproxy uses proxy servers to execute a DDoS.
  • .httppost is a POST flood.
  • .httpsmartflood bypasses all cookie protection unless its captcha.
  • .syn TCP flood which bypasses OVH.
  • .udp is basic UDP flood.

 

Observed Command Traffic

ASERT observed and was able to capture DDoS and command traffic from a portion of the purported attack types available to MedusaHTTP.

.httpseebix

This command sends GET requests using 1 of 12 user agents randomly chosen from a predefined list, similar to the below example:

MedusaHTTP .httpseebix command traffic

.httpstrong

This command appears to be similar to .httpseebix however this uses only one hardcoded user agent to perform http GET request.

.httpoverload

This command appears to be the same as .httpseebix; Stevenkings claims it has the ability to crash certain servers.

.httpactive

This command is advertised as a mixture of TCP and Layer 7 Flooding that has the ability to take down servers. Below you can see the utilization of multiple GET requests with a TCP packet of “0000000” in between them, illustrating this technique.

MedusaHTTP .httpactive command traffic

.smartflood (GET)

This command is purported to bypass cookie protection by StevenKings. The POST version of this command takes an additional parameter ‘Payload’ which, in this example, is ‘hello=hello’.

MedusaHTTP .smartflood POST command traffic

There is also a GET version of this command which looks similar however does not include the POST data.

MedusaHTTP .smartflood GET command traffic

.download

This command instructs the bot to download and run executables, which could be a bot update or additional malicious files. The method of downloading the executables is a simple HTTP GET request.

.stop-all

This command instructs the bot to stop all active attacks.

 

Conclusion

MedusaHTTP has evolved from its prior IRC version. Although there is a new command and control communication mechanism, a large amount of functionality overlap remains. Many of the DDoS traffic examples above are exactly the same profile of traffic generated by MedusaIRC and continue to be mitigated in the same way using situationally appropriate firewall ACLs and other countermeasures available in Arbor products including HTTP Authentication, Zombie Detection, and AIF Malware Family Blocking.

 

Indicators

Samples:

  • 2919a13b964c8b006f144e3c8cc6563740d3d242f44822c8c44dc0db38137ccb
  • 85ebf6330039de69dbef1a4860274f21d8b980adb9c3d8385873c5d697c61685
  • e514935ab07b29ca1ee9eedaf699de202ada70e29b4fc4618908b8ca8b3f83ef
  • 290eb4666848172a03c9c5123c004278647e8f5445a7d4e9c29a9ecc58c1b329
  • 4654f4cbd9e3910f4901493b9774d978060f1c9a9489612b66d66ee61667f60f

Command and Control Domains:

  • Disability[.]su
  • Franchessko[.]top
  • Ircnews[.]wang
  • Kjnsfiosgjnlorgiko[.]ru
  • Mhforum[.]biz
  • Missyiurfound[.]bid
  • scam-financial[.]org
  • sgsdgsdger[.]ru
  • troyamylove[.]gdn
  • wooow1[.]ru
  • youframegood[.]ru

Go to Source
Author: TJ Nelson

More trouble in Google Play land

This is not a good week for Google, it seems.

After our mobile security experts repeatedly discovered adware on several apps on the Google Play store, our friends at Symantec have unearthed at least eight malicious apps that are found capable of adding affected mobile devices to a botnet. According to their blog post, the apps have been downloaded and installed onto 2.6 million smartphones, tablets, and possibly some IoTs.

Threat actors behind the bogus apps have banked on the popularity of Minecraft, a sandbox video game with a user base of 100 million. They specifically targeted Minecraft: Pocket Edition (PE), which  launched in 2015. Symantec explained how the malicious apps work:

The app connects to a command and control (C&C) server on port 9001 to receive commands. The C&C server requests that the app open a socket using SOCKS and wait for a connection from a specified IP address on a specified port. A connection arrives from the specified IP address on the specified port, and a command to connect to a target server is issued. The app connects to the requested target server and receives a list of ads and associated metadata (ad type, screen size name). Using this same SOCKS proxy mechanism, the app is commanded to connect to an ad server and launch ad requests.

There is no functionality within the application to display ads.

Due to a large number of devices affected, it’s possible for the threat actors to also leverage them for DDoS attacks. This is not a new concept—using mobile devices to launch a crippling blow to websites and networks has been done before.

To minimize the possibility of downloading apps that are not behaving like they’re supposed to, consult our list of safe practices when using your mobile device. Meanwhile, users of Malwarebytes for Android who have updated to the latest version are already protected. We detect the malicious apps as Android/Backdoor.Clientor.fun.

Stay safe, everyone!

The post More trouble in Google Play land appeared first on Malwarebytes Labs.

Go to Source
Author: Malwarebytes Labs