Category: botnet

Sep 12 2017

Android Click-Fraud App Repurposed as DDoS Botnet

The McAfee Mobile Research Team tracks the behavior of Android click-fraud apps. We have detected multiple implementations, including recent examples on Google Play in 2016 and Clicker.BN last month. These threats are characterized by a common behavior: They appear innocuous but in the background they perform HTTP requests (simulating clicks) on paid “advertainment” to make money for a specific developer.

This behavior means that a URL is permanently requested via HTTP. Hypothetically, if the target and frequency of that request were modified, we could classify it as a DDoS attack. After all, the app uses the same main malware functionality and botnet infrastructure. From ad fraud to DDoS is only one step—and that is what some variants of Clicker.BN have taken. We have now seen click-fraud Android Trojans repurposed to perform DDoS attacks.

Most of the control servers of this Android/Clicker botnet—aka WireX—were taken down in late August.

The apps that perform click-fraud and those that launch DDoS attacks have much in common: the technique to configure headers from the control server, the domains axclick[.]store and ww[56]8[.]ybosrcqo.us (which have been taken down though others remain active), how they keep control server parameters updated in the local cache, and how the target server performs each HTTP request without loading cache data. They are share methods of obfuscation, packing strategies, and methodology for publishing on Google Play.

The apps do have differences, however. The control server subdomain and GET methods vary, as well as the delimiters used to split the received parameters and the order and data of received parameters:

  • Click-fraud components receive:
    • Target URL
    • JavaScript function (to simulate mouse-over clicks)
    • User agent
    • Google Play package
  • DDoS components receive:
    • Target URL
    • User agent
    • HTTP referrer (same as target URL in our tests)

The DDoS variants put the traffic generation in a loop to fully complete each HTTP request many times:

DDoS authors increased the frequency of the HTTP requests to 100 per minute. (Click-fraud implementations send a request each 55 seconds using same code structure.)

Other DDoS variants perform a UDP flood attack on the target, based on data received from the control server (host and port) and implemented as follows:

The previous thread (C1343a) is executed 50 times by the following method (m7240a), which is invoked after loading the parameters from the control server. These are refreshed every 50, 55, or 60 seconds (depending on the variant).

All variants of this threat use an uncommon method to receive and parse parameters from the control server: They arrive inside the title tag of an HTML file, and vary based on a key string used to parse the parameters. We discussed this in our analysis of Clicker.BN.

We mentioned some other curiosities in our Clicker.BN post. The delimiter strings look a bit like anagrams: “WireX” comes from the string “snewxwri.” Early Clicker.BN variants used the delimiter “eindoejy,” which could represent “I enjoyed” or “die enjoy.” More delimiters are present in other variants of this threat.

 

Click fraud in 2017 could cost US$16 billion, according to one source. DDoS attacks have their own underground market. Moving from one mobile threat to another is not new. We have seen Android ransomware switch to banking Trojans (in 2016) and premium SMS Trojans move to wireless application protocol billing.

Malware authors pursue profits with different strategies, taking advantage of already developed infrastructure. In this case, Android/Clicker.BN created a mobile botnet and distributed the infecting vector on Google Play, repackaging the threat to look like a clean app and widely distributing it across the globe. The authors modified this malware only a little bit to launch the massive DDoS attack known as WireX.

McAfee Mobile Security detects this threat as Android/Clicker.BN!Gen and prevents its execution. To further protect yourself against malicious apps, use only legitimate app stores, and pay attention to suspicious traits such as nonsense names, missing descriptions, and poor user reviews. Also, verify that the app’s request for permissions are related to its functionality. Be wary when apps request device administration API access, which is usually requested only by security apps, antimalware, mobile device management, or corporate email clients. Most apps and games will never ask for device admin rights.

The post Android Click-Fraud App Repurposed as DDoS Botnet appeared first on McAfee Blogs.

May 03 2017

Mirai, BrickerBot, Hajime Attack a Common IoT Weakness

We know that devices in the Internet of Things make enticing targets for attack. They are often insecure and can act as open windows into trusted networks. Cybercriminals are capitalizing on that more and more each day, gathering hundreds of thousands of insecure IoT devices into giant botnets. Remember what happened last fall when Mirai malware conducted the largest DDoS attack we have seen so far. The downstream effect of that attack was that millions of people could not reach such popular sites as Twitter, Spotify, Box, The New York Times, and Airbnb.

Now, two new attacks targeting IoT devices have emerged. The BrickerBot malware has been infecting and “bricking” poorly secured IoT devices. It is said that the BrickerBot operator is making these devices unusable to keep Mirai from infecting the same devices. Apparently, this attacker may be a modern-day vigilante.

The second attack is based on malware called Hajime. It appears to use its power for good instead of evil, actually securing the IoT devices it infects to protect them from more malicious attacks like Mirai. However, because the devices have been infected by Hajime, there is nothing stopping the Hajime botnet operator from changing their objectives.

What do these attacks have in common? They all take advantage of poor network and credential management. In these attacks, the malware scans for open Telnet or SSH ports, discovers IoT devices behind them, performs brute-force attacks using a dictionary of common default usernames and passwords, and then looks for ways to send the malware payload. Once infected, each malware family has different objectives, as we discussed above.

Given that these IoT device attacks follow the same attack sequence, why don’t IoT device makers simply address their weaknesses? And if they address the problems of poor network and credential management, will that solve the IoT device security problem once and for all?

We offered an answer to the first question in the McAfee Labs 2017 Threats Predictions report. In that report, we said that in their drive to be first to market with certain types of IoT devices, developers focus on features designed to capture early adopters. Unfortunately, sound security is usually not at the top of the list of must-have features by that class of buyers. Further, the use of poorly written, insecure third-party code libraries can exacerbate the problem. So, until the IoT device land rush subsides, we will probably continue to see obvious security weaknesses.

Addressing the problems of poor network and credential management will solve only the IoT device security weaknesses being exploited today. There will be other exploited weaknesses tomorrow.

The right way to look at security in an IoT device is by using an assist such as the OWASP IoT Attack Surface model. From an attacker’s point of view, an IoT device is very similar to any other computer system and should be assessed for security just as with other systems. I created this previously unpublished image last year to make the point:

This is the toaster attack surface!

In fact, when our threat research team examines an IoT device for security weaknesses, they use the OWASP model for guidance. If IoT device makers simply examined their products during development through an attacker’s lens, they could reduce the number of security weaknesses significantly.

What can you do today to mitigate IoT device security weaknesses? Some weaknesses unfortunately fall into the category of acceptable risk. Other weaknesses, however, can be addressed. Check out the Solution Brief “Secure IoT Devices to Protect Against Attacks” to learn more. In that brief, we offer actionable policies and procedures for securing IoT devices. We also provide detailed advice on how McAfee products can protect systems and networks from IoT device attacks.

To stay up to date on all cybersecurity news, follow @McAfee and @McAfee_Labs.

The post Mirai, BrickerBot, Hajime Attack a Common IoT Weakness appeared first on McAfee Blogs.

Apr 28 2017

Hajime Botnet Reaches 300,000 Hosts With No Malicious Functions

This is not the first IoT heavy botnet, Mirai takes that title, the interesting part is the Hajime botnet appears to be benign. So far no malicious functions have been detected in the codebase, other than the ability to replicate itself and block other malware, Hajime seems to have no DDoS or offensive mechanisms. Hajime […] The post Hajime...

Read the full post at darknet.org.uk
Apr 20 2017

Mirai Botnet Creates Army of IoT Orcs

This post was based on analysis by Yashashree Gund and RaviKant Tiwari.

There is a lot of speculation in the news about surveillance from home appliances, personal electronics, or other Internet of Things (IoT) devices. Although some statements may be hyperbole, we know that these devices, in homes and offices, are being compromised and used to attack others.

On October 21, 2016, the first major cyberattack using IoT devices as weapons was a massive flood of network traffic aimed at Dyn, a company that operates domain name and traffic optimization services. Peak traffic was measured at 1.2Tbps, the highest ever recorded for this type of attack. Analysis revealed that the attack came from a large number of webcams, compromised by Mirai botnet malware.

Mirai infects most IoT devices by scanning for open Telnet or SSH ports, and then using a short dictionary of common default usernames and passwords to break into vulnerable devices. After gaining entry, the malware drops a small binary program on the device, which fetches the full Mirai bot executable. Each infected bot searches for other vulnerable IoT devices, rapidly expanding the botnet. A network scan conducted by McAfee in late 2016 identified 40,000 infected IoT devices active and online, about 2.5 million infected devices that were offline, and about five devices newly infected every minute.

During the infection phase, the control server monitors the infection process until it “owns” enough IoT devices for whatever campaign the attacker has planned. When the attacker decides to initiate an attack, commands are sent to the bots to select the attack type and target. Mirai is capable of executing almost a dozen attack types at different layers, making it difficult to intercept. When the attacker determines that countermeasures are reducing the effectiveness of one attack type, Mirai can quickly switch to another type, working at the network, transport, or application layers.

Before the October attack on Dyn, the Mirai source code was released, and several Mirai-based botnets began offering attacks-as-a-service, using up to 100,000 bots, for less than $0.08 per bot. Since the source code release, additional Mirai variants have surfaced, as other cybercriminals look to build on the success of this malware family. We expect a steady release of new variants, targeting different devices, attack types, antidefense measures, and evasion techniques. The source code and attack-as-a-service offerings have made Mirai available to a wide range of individuals, greatly expanding the list of potential victims.

To test Mirai’s attack methods and infection speed, we set up a “honeypot,” simulating a vulnerable IoT device. (Watch our video.) Within a minute, we registered the first attempt to log in with default credentials.

We also monitored Mirai attack activity during a two-day period and counted 34 attacks by multiple Mirai botnets, mostly against targets in the United States, but also some in Germany, the Netherlands, and the United Kingdom. Targets were mostly gaming servers, as well as a few individuals, web shops, a dating site, and even another attack site. This would appear to confirm that even amateur attackers can use Mirai for their own ends.

The best defense against Mirai attacks on IoT devices is to change default passwords and usernames, and to use strong and unique passwords across all devices. The list of passwords used by Mirai to compromise IoT devices is disturbingly short and basic, including variations of “12345,” “admin,” “password,” “default,” and the name of the manufacturer. To bolster defenses, keep IoT device software up to date, segment IoT devices from other parts of the network, disable unused device services and ports, and periodically power-cycle IoT devices.

For more information on Mirai and best practices for securing your network and IoT devices, download the McAfee Labs Threats Report: April 2017.

The post Mirai Botnet Creates Army of IoT Orcs appeared first on McAfee Blogs.