Down to the WireX
Over the course of the last few weeks, a botnet comprised mainly of Android mobile devices has been utilized to launch a high-impact DDoS extortion campaign against multiple organizations in the travel and hospitality sector. This botnet, dubbed ‘WireX’, is only the second mobile botnet to have been confirmed to date as being used to launch DDoS attacks, and the first mobile botnet known to have been used in a DDoS extortion campaign.
A rapid, coordinated, round-the-clock response between network operators, content-delivery network (CDN) operators, authoritative DNS registrars/hosters, security researchers and Google has resulted in the identification of the Android applications into which the botnet code was seeded, its command-and-control infrastructure, and the removal of the compromised applications from Google Play. Google has also taken action to force the de-installation of this malware from Android devices which are configured to download and update applications from Google Play, and to prevent similar compromised applications from being uploaded to Google Play in future.
WireX Botnet and DDoS Attack Methodology
The botted Android devices in the WireX botnet were capable of launching HTTP and HTTP/S application-layer attacks against designated targets. As WireX was originally used by its operators to commit click-fraud prior to their venture into DDoS extortion, WireX did not have the ability to generate others types of DDoS attack traffic.
While the attacker began by using easily-identifiable HTTP User-Agents, it was clear that as defenders successfully mitigated the attacks, the attacker was monitoring attack efficacy and began changing the User-Agents and other attack traffic characteristics in response. This suggests that the attacker did not have much experience launching DDoS attacks, but learned rapidly to try different techniques to try to thwart the defenders.
The mobile aspect of the WireX botnet resulted in a higher-than-normal churn of attacking source IPs; as the unwitting owners of botted Android devices moved from LAN to LAN, or mobile data cell to mobile data cell, the IP addresses of the attacking devices often changed. Also, some proportion of mobile device owners power down their devices when not in use, which often results in different IP addresses being assigned to the same devices upon startup.
Several of the organizations involved in the WireX analysis and remediation effort have compiled a report of the details of the Android bot code and its command-and-control infrastructure – prominent investigative reporter and security researcher Brian Krebs has posted an excellent overview of their findings, as well as providing links to the actual report itself. Krebs’ article may be found here.
A Firm Foundation Ensures Resilience to Attacks
In addition to understanding how this particular botnet was constructed and operated, it’s important that organizations implement best current practices (BCPs) for their network infrastructure, application/service delivery stacks, and ancillary supporting services. This will allow the organization to maintain availability and ensure continuous service delivery even in the face of attack.
Network infrastructure BCPs such as infrastructure ACLs (iACLs) to protect routers and layer-3 switches from attack, transit ACLs (tACLs) to enforce situationally-specific network access policies, and a sound, scalable network topology, are extremely important. While WireX did not attack network infrastructure devices directly, many botnets are capable of doing so and attackers will often choose to target the network itself rather than end-hosts, in hopes of causing a loss of availability due to lack of preparation on the part of the defenders. An overview of network infrastructure BCPs may be found here.
Application/service delivery stacks must be designed, implemented, and operated in a scalable, resilient manner which allows not only for the highest possible degree of self-protection, but for defenders to have the ability to quickly detect, classify, and traceback DDoS attack traffic. BCPs in this arena include architectural principles such as clear separation between public-facing front-ends and application/service back-ends, reverse proxies to provide layer-7 policy enforcement and inspection of encrypted traffic such as HTTP/S, well-defined URI schemas, as well as ensuring that packets from outside the organization’s network can never directly reach servers and other key delivery elements. Instead, all connections, queries, transactions, responses, etc. should be mediated at both layer-4 and layer-7. For HTTP and HTTP/S, reverse-proxies such as NGINX should be implemented; for authoritative DNS, a logically-segmented DNS architecture making use of hidden masters and external resolvers is strongly recommended.
Elements of DDoS Defense
Every year, Arbor conducts a survey of network operators worldwide, including ISPs, enterprises, CDN operators, wireless and wireline broadband access providers, etc. The results of this survey are published in the annual Arbor Worldwide Infrastructure Security Report (WISR).
One of the key findings of the WISR is that many organizations do not have a DDoS defense plan in place; of the subset which do, many of those organizations have never rehearsed their plan. It is critical that organizations devise and rehearse their DDoS defense plans in order to ensure that they have the requisite personnel, skills, operational processes, communications plans, and support services in place to defend their Internet properties in a timely and effective manner.
Organizations must have the ability to detect, classify, and traceback DDoS attack traffic; they must be able to distinguish between normal traffic patterns and abnormal, and potentially harmful, Internet traffic. Arbor SP provides insight into all Internet traffic ingressing and egressing the network, and alerts the operational security team for both pathological DDoS traffic such as SYN-floods, UDP and TCP reflection/application attacks, DNS query floods, etc., but also to shifts in apparently semantically correct traffic which can represent layer-7 DDoS attacks focused on HTTP and HTTP/S.
Arbor APS and TMS are intelligent DDoS mitigation systems (IDMSes) with a full suite of active DDoS countermeasures, including functionality specifically designed to mitigate layer-7 HTTP and HTTP/S DDoS attacks such as those launched by the WireX Android botnet. Additionally, network infrastructure-based mitigation techniques such as source-based remotely-triggered blackholing (S/RTBH) and flowspec can also be leveraged using Arbor solutions.
Arbor Cloud offers a managed DDoS mitigation service utilizing Arbor DDoS defense solutions, which can be leveraged as an entirely cloud-based mitigation solution, or in a hybrid DDoS defense architecture consisting of both cloud-based and customer premise-deployed Arbor solution elements.
WireX is a reference case for how botnets originally intended for purposes such as click-fraud and spam can be re-purposed to launch DDoS attacks. And it is also a harbinger of things to come; we anticipate significant growth in the abuse of mobile devices to launch DDoS attacks.
At the same time, the architectural principles, tools, techniques, processes, and skills required to mitigate DDoS attacks launched by fixed-node botnets also apply to WireX and similar mobile botnets. Organizations which implement the BCPs noted above will be well-prepared to mitigate DDoS attacks from botnets of any type, including mobile botnets such as WireX, now and in the future.