Smoking Guns – Smoke Loader learned new tricks


Cisco Talos has been tracking a new version of Smoke Loader — a malicious application that can be used to load other malware — for the past several months following an alert from Cisco Advanced Malware Protection’s (AMP) Exploit Prevention engine. AMP successfully stopped the malware before it was able to infect the host, but further analysis showed some developments in the Smoke Loader sample resulting from this chain of malware that intrigued us. This includes one of the first uses of the PROPagate injection technique in real-world malware. Besides a report released at the end of last week describing a different RIG Exploit Kit-based campaign, we haven’t seen real-world malware using this.

Talos is very familiar with Smoke Loader. For example, it was used as a downloader for a cyberattack that was launched using the official website of Ukraine-based accounting software developer Crystal Finance Millennium (CFM) in January.

Similar to many other campaigns, the initial infection vector was an email with a malicious Microsoft Word document attached. The victims were tricked into opening the attachment and enabling the embedded macros. This started the malware-downloading chain, down to the final Smoke Loader infection and its plugins.

Smoke Loader is primarily used as a downloader to drop and execute additional malware like ransomware or cryptocurrency miners. Actors using Smoke Loader botnets have posted on malware forums attempting to sell third-party payload installs. This sample of Smoke Loader did not transfer any additional executables, suggesting that it may not be as popular as it once was, or it’s only being used for private purposes.

The plugins are all designed to steal sensitive information from the victim, specifically targeting stored credentials or sensitive information transferred over a browser — including Windows and Team Viewer credentials, email logins, and others.



As mentioned above, the infection chain started with an email and an attached malicious Word document (b98abdbdb85655c64617bb6515df23062ec184fe88d2d6a898b998276a906ebc). You can see the content of this email below.

Fig. 1 – Phishing Email

The attached Word document had an embedded macro that initiated the second stage and downloaded the Trickbot malware. (0be63a01e2510d161ba9d11e327a55e82dcb5ea07ca1488096dac3e9d4733d41).

Fig. 2 – Email attachment: IO08784413.doc

This document downloads and executes the Trickbot malware from hxxp://5[.]149[.]253[.]100/sg3.exe, or hxxp://185[.]117[.]88[.]96/sg3.exe as %TEMP%\[a-zA-Z]{6-9}.exe. These URLs have served up multiple malicious executables in the past, including samples of Trickbot.

In our Trickbot cases, the malware finally downloaded the Smoke Loader trojan (b65806521aa662bff2c655c8a7a3b6c8e598d709e35f3390df880a70c3fded40), which installed five additional Smoke Loader plugins. We are describing these plugins in detail later in the plugins section of this report.



Smoke Loader has often dropped Trickbot as a payload. This sample flips the script, with our telemetry showing this Trickbot sample dropping Smoke Loader. This is likely an example of malware-as-a-service, with botnet operators charging money to install third-party malware on infected computers. We haven’t analysed the Trickbot sample further, but for your reference, we are providing the Trickbot configuration here (IP addresses redacted with bracketed dots for security reasons.):


<module name=”systeminfo” ctl=”GetSystemInfo”/>
<module name=”injectDll”/>


Malware frequently iterates through process lists to find a process to inject. Security researchers know this process well and have created many tools to track the Windows APIs used in this technique, like CreateToolhelp32Snapshot. This Smoke Loader sample avoids iterating through process lists by calling the Windows API GetShellWindow to get a handle to the shell’s desktop window, then calling GetWindowThreadProcessId to get the process ID of Explorer.exe.

Smoke Loader then uses standard injection API to create and write two memory sections in Explorer, one for shellcode and another for a UxSubclassInfo structure to be used later for PROPagate injection.

GetShellWindow -> GetWindowThreadProcessId -> NtOpenProcess -> NtCreateSection -> NtMapViewOfSection x2 -> NtUnmapViewOfSection

The window handle retrieved from the previous call to GetShellWindow has a second purpose. Smoke Loader uses EnumChildWindows to iterate through each of the handle’s child windows to find one containing the property UxSubclassInfo, which indicates it is vulnerable to PROPagate injection.

PROPagate injection was first described by a security researcher in late 2017, though there were no public POCs available when Smoke Loader started using it. The Smoke Loader developers likely used publicly available notes on PROPagate to recreate the technique.

Fig. 3 – PROPagate Injection

For each child window, the injector calls EnumPropsA to iterate through window properties until it finds UxSubclassInfo. This function also showcases some of the anti-analysis techniques employed by this sample’s packer. There are several unnecessary jumps for control flow obfuscation, including simple opaque predicates leading to junk code.

“Deobf_next_chunk” takes arguments for size and offset for the next chunk of code to deobfuscate and execute, so the bulk of the malicious code is deobfuscated as needed, and can be obfuscated again once the next chunk is loaded. The obfuscation method is a simple one-byte XOR with the same hardcoded value for every piece.
These anti-analysis techniques are accompanied by anti-debugging and anti-VM checks, as well as threads dedicated to scanning for processes and windows belonging to analysis tools. These features complicate forensics, runtime AV scanners, tracing, and debugging.

Fig. 4 – Trigger malicious event handler via WM_NOTIFY and WM_PAINT

Once the shellcode and UxSubclassInfo data are written to the remote process, the injector calls SetPropA to update the property for the window, then sends WM_NOTIFY and WM_PAINT messages to the target window to force it to trigger the malicious event handler that executes the injected shellcode.


Smoke Loader received five interesting plugins instead of additional payloads. Each plugin was given its own Explorer.exe process to execute in, and the malware used older techniques to inject each plugin into these processes. Each Explorer.exe process is created with the option CREATE_SUSPENDED, the shellcode is injected, then executed using ResumeThread. This is noisy and leaves six Explorer.exe processes running on the infected machine.


As mentioned above, the plugins are all designed to steal sensitive information from the victim, explicitly targeting stored credentials or sensitive information transferred over a browser. Each plugin uses the mutex “opera_shared_counter” to ensure multiple plugins don’t inject code into the same process at the same time.

Plugin 1:

This is the largest plugin with approximately 2,000 functions. It contains a statically linked SQLite library for reading local database files.

  • It targets stored info for Firefox, Internet Explorer, Chrome, Opera, QQ Browser, Outlook, and Thunderbird.
  • Recursively searches for files named logins.json which it parses for hostnameencryptedUsername, and encryptedPassword.
  • vaultcli.dll – Windows Credential Manager
  • POP3, SMTP, IMAP Credentials

Plugin 2:

This plugin recursively searches through directories looking for files to parse and exfiltrate.

The Bat!

Plugin 3:

This one injects into browsers to intercept credentials and cookies as they are transferred over HTTP and HTTPS.

  • If “fgclearcookies” is set, kills browser processes and deletes cookies.
  • iexplore.exe and microsoftedgecp.exe 
    • HttpSendRequestA 
    • HttpSendRequestW 
    • InternetWriteFile 
    • firefox.exe
  • PR_Write in nspr4.dll or nss3.dll
  • chrome.exe 
    • unknown function inside chrome.dll
  • opera.exe 
    • unknown function inside opera_browser.dll or opera.dll

Plugin 4:

This hooks ws2_32!send and ws2_32!WSASend to attempt to steal credentials for ftp, smtp, pop3, and imap

Plugin 5:

This one injects code into TeamViewer.exe to steal credentials


B98abdbdb85655c64617bb6515df23062ec184fe88d2d6a898b998276a906ebc (IO08784413.doc)
0be63a01e2510d161ba9d11e327a55e82dcb5ea07ca1488096dac3e9d4733d41 (Trickbot)
b65806521aa662bff2c655c8a7a3b6c8e598d709e35f3390df880a70c3fded40 (Smoke Loader)

Mutex: opera_shared_counter

Trickbot IPs:

Smoke Loader domains:

Dropped File: %appdata%\Microsoft\Windows\[a-z]{8}\[a-z]{8}.exe

Scheduled Task: Opera scheduled Autoupdate [0-9]{1-10}


We have seen that the trojan and botnet market is constantly undergoing changes. The players are continuously improving their quality and techniques. They modify these techniques on an ongoing basis to enhance their capabilities to bypass security tools. This clearly shows how important it is to make sure all our systems are up to date. Organizations can utilize a multi-layered defensive approach to detect and protect against these kinds of threats. Talos continues to monitor these campaigns as they evolve to ensure that defenses protect our customers. We strongly encourage users and organizations to follow recommended security practices, such as installing security patches as they become available, exercising caution when receiving messages from unknown third parties, and ensuring that a robust offline backup solution is in place. These practices will help reduce the threat of a compromise, and should aid in the recovery of any such attack.

Go to Source
Author: Talos Group

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


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: (that resolves to: 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:


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:


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.


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