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.


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



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


Conhive site keys:


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.



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 [] [page.php] [threads] [delay] [stoptime]
  • .httpoverload [] [page.php] [threads] [delay] [stoptime]
  • .httpstrong [] [page.php] [threads] [delay] [stoptime]
  • .httpactive [] [page.php] [threads] [delay] [stoptime]
  • .httpssl [] [page.php] [threads] [delay] [true/false] [stoptime]
  • .proxy [] [page.php] [webpagewithproxy] [threads] [delay] [stoptime]
  • .httppost [] [page.php] [postcontent] [threads] [delay] [stoptime]
  • .smartflood [GET] [] [page.php] [threads] [delay] [stoptime]
  • .smartflood [POST] [] [page.php] [postcontent] [threads] [delay] [stoptime]
  • .syn [host] [port] [sockets] [threads]
  • .udp [host] [port] [sockets] [threads] [packetsize]
  • .download [] [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.


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


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


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


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


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.


This command instructs the bot to stop all active attacks.



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.




  • 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/

Stay safe, everyone!

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

Go to Source
Author: Malwarebytes Labs