Josh Lefkowitz
Chief Executive Officer
Josh Lefkowitz executes the company’s strategic vision to empower organizations with the fastest, most comprehensive coverage of threatening activity on the internet. He has worked extensively with authorities to track and analyze terrorist groups. Mr. Lefkowitz also served as a consultant to the FBI’s senior management team and worked for a top tier, global investment bank. Mr. Lefkowitz holds an MBA from Harvard University and a BA from Williams College.
Evan Kohlmann
Chief Innovation Officer
Evan Kohlmann focuses on product innovation at Flashpoint where he leverages fifteen years’ experience tracking Al-Qaida, ISIS, and other terrorist groups. He has consulted for the US Department of Defense, the US Department of Justice, the Australian Federal Police, and Scotland Yard’s Counter Terrorism Command, among others. Mr. Kohlmann holds a JD from the Univ. of Pennsylvania Law School and a BSFS in International Politics from the Walsh School of Foreign Service at Georgetown Univ.
Josh Devon
Chief Operating Officer / Chief Product Officer
Josh Devon focuses on product vision and strategy at Flashpoint while ensuring the company’s departments function synergistically during its rapid growth. He also works to ensure that customers receive best in class products, services, and support. Previously, Mr. Devon co-founded the SITE Intelligence Group where he served as Assistant Director. He holds an MA from SAIS at Johns Hopkins Univ. At the Univ. of Pennsylvania, he received a BS in Economics from the Wharton School and a BA in English from the College of Arts and Sciences.
Chris Camacho
Chief Revenue Officer
As Chief Revenue Officer, Chris Camacho leads the company’s global sales team, which includes solution architecture, business development, strategic integrations, partnerships, and revenue operations; he is also the architect of Flashpoint’s FPCollab sharing community. With over 15 years of cybersecurity leadership experience, he has spearheaded initiatives across Operational Strategy, Incident Response, Threat Management, and Security Operations to ensure cyber risk postures align with business goals. Most recently as a Senior Vice President of Information Security at Bank of America, Mr. Camacho was responsible for overseeing the Threat Management Program. An entrepreneur, Mr. Camacho also serves as CEO for NinjaJobs: a career-matching community for elite cybersecurity talent. He has a BS in Decision Sciences & Management of Information Systems from George Mason University.
Lisa Iadanza
Chief People Officer
Lisa M. Iadanza leads all functional areas of People Operations at Flashpoint, including human resources, talent acquisition & management, employee engagement, and developing high performance teams. In addition to collaborating with the executive team to drive strategic growth, she plays an integral role in fostering Flashpoint’s culture and mission. Driven by her passions for mentorship, employee advocacy, and talent development, Ms. Iadanza has more than twenty years of experience in building, scaling, and leading human resources functions. Prior to Flashpoint, she held leadership roles at Conde Nast, Terra Technology, and FreeWheel. She is a member of the Society for Human Resources Management (SHRM) and holds a bachelor’s degree in management with concentrations in human resources and marketing from State University of New York at Binghamton.
Donald Saelinger
Donald Saelinger is responsible for driving strategic and operational initiatives to accelerate Flashpoint’s growth and scale. In this role, Donald leads a broad portfolio including Marketing, Customer Success, Revenue Operations, Legal and related functions, and is focused on helping the company execute on a go-to-market approach that maximizes value to our customers. Prior to Flashpoint, Donald served as Chief Operating Officer and General Counsel of Endgame, Inc., an endpoint detection and response company acquired by Elastic N.V. in 2019, and where he led a range of teams focused on growth, scale, and legal and compliance matters. Donald also previously served as the General Counsel and Chief Compliance Officer at Opower, Inc. (NYSE: OPWR), a global provider of SaaS solutions to electric and gas utilities that was acquired by Oracle, Inc. in 2016. Donald graduated from Columbia University in 2000 and received his JD from the Georgetown University Law Center in 2006.
Rob Reznick
SVP Finance and Corporate Development
Rob Reznick leads the finance, accounting, and corporate development teams at Flashpoint. Rob previously served as Director of Finance & Accounting for 1010data (acquired by Advance/Newhouse), and Director of Finance for Financial Guard (acquired by Legg Mason) after prior work in forensic accounting and dispute consulting. Mr. Reznick is a Certified Public Accountant and holds an MBA and MAcc from the Fisher College of Business at the Ohio State University, and a BBA from the Ross School of Business at the University of Michigan.
Tom Hofmann
SVP Intelligence
Tom Hofmann leads the intelligence directorate that is responsible for the collection, analysis, production, and dissemination of Deep and Dark Web data. He works closely with clients to prioritize their intelligence requirements and ensures internal Flashpoint operations are aligned to those needs. Mr. Hofmann has been at the forefront of cyber intelligence operations in the commercial, government, and military sectors, and is renowned for his ability to drive effective intelligence operations to support offensive and defensive network operations.
Jake Wells
SVP Solutions Architecture
Jake Wells leads strategic integrations and information sharing as part of the client engagement & development team, which serves as an internal advocate for our government and commercial clients to ensure Flashpoint’s intelligence solutions meet their evolving needs. He leverages a decade of experience running cyber and counterterrorism investigations, most recently with the NYPD Intelligence Bureau, to maximize the value customers generate from our products and services. Mr. Wells holds an MA from Columbia University and a BA from Emory University.
Brian Brown
SVP Strategy and Business Development
Brian Brown is responsible for the overall direction of strategic sales and development supporting Flashpoint’s largest clients. In his role, Mr. Brown focuses on designing and executing growth-oriented sales penetration strategies across multiple vertical markets, including both Government and Commercial, supporting Flashpoint’s Sales and Business Development Teams. An experienced entrepreneur, Mr. Brown also serves as CSO for NinjaJobs, a private community created to match elite cybersecurity talent with top tier global jobs and also advise growth-stage cybersecurity companies.
Justin Rogers
VP Revenue Operations
Justin Rogers leads the Revenue Operations team at Flashpoint, aligning sales, marketing, partnerships, customer success, and finance across vision, planning, process, and goals. He leverages over 15 years of experience in security, strategy, product design, and implementation to drive growth, provide an end-to-end view of the customer journey, and a seamless customer experience. Recently, Justin led Marketing for Centripetal, bringing the first Threat Intelligence Gateway to market. Previously, he managed operations of a Counter IED lab electronics forensics division while forward deployed in support of Operation Iraqi Freedom and Operation Enduring Freedom in Afghanistan. Justin holds a BS in Electrical Engineering from the University of New Hampshire.
Peter Partyka
VP Engineering
Peter Partyka leads Flashpoint’s engineering teams. Peter previously worked in the quantitative hedge fund space in New York City, implementing security and administrative solutions around proprietary trading platforms, high-availability cloud deployments, and hardening of applications and infrastructure. Peter leverages more than 16 years of experience in technology specializing in application security, red-teaming, penetration testing, exploit development, as well as blue-teaming. Peter has a long track record of managing tech teams and implementing engineering security best practices. Recently Peter led Flashpoint toward GDPR and CCPA compliance and has been a key architect of Flashpoint’s robust compliance programs. Peter has taught advanced cybersecurity courses at New York University and consulted at various tech startups during his career.
Paul Farley
Paul Farley is responsible for the Asia-Pacific region of Flashpoint's international business, including Australia, Japan, and Singapore. In his role at Flashpoint, Paul is executing growth-oriented sales strategies across multiple countries and vertical markets, including both Government and Commercial. Paul has extensive experience leading regional sales for both pre-IPO growth businesses and large organizations such as RSA, EMC and DELL.
Steven Cooperman
VP Public Sector Sales
Steven Cooperman is responsible for Flashpoint’s strategy and sales growth of its public sector business. He also supports the development of a robust partner ecosystem for public sector business to deliver value added offerings and innovation focused to the mission of government. Steven has an established and diverse career in the Public Sector, holding leadership positions at a number of successful enterprise software companies and Federal System Integrators, including ServiceNow, HP, Oracle and Northrop Grumman. He holds an MA in Analytic Geography from the State University of New York - Binghamton, and received his BS in Geology from the State University - Oneonta.
Matthew Howell
VP Product
Matthew Howell leads the Product Management and Product Marketing teams for Flashpoint. He is responsible for developing a strong team that drives product adoption and user engagement through outcome based prioritization, continuous process improvement, and metrics driven development. Matthew brings a passion for diverse ideas, experience launching B2B SaaS products, building integration ecosystems, supporting five 9s SLAs, and leading distributed teams. He holds a bachelor’s degree in computer science from the University of Virginia
Glenn Lemons
Executive Director Strategic Accounts Engagement
Glenn Lemons is Executive Director, Strategic Accounts Engagement at Flashpoint. He previously served as the acting Director of Citigroup's Cyber Intelligence Center where he was responsible for analyzing and reacting to intelligence from a variety of threats. These threats ranged from fraudulent activity and attempting to defraud Citi's clients to supporting security operations for the firm's worldwide network presence. He has extensive experience working with multiple clients across the financial services, manufacturing, healthcare, and public sectors. Glenn also has more than 26 years of intelligence experience within the operational and support communities in the U.S. military and federal civilian service; seven of which focused on both defensive and offensive cyber operations. While working for the U.S. Department of Homeland Security, he testified numerous times before U.S. Congressional committees and member requested open and closed sessions.
Steve Leightell
Steve started his career in Internet sales in the early 1990s and was always a top sales rep before transitioning to business development. By the early 2000s, he was the Director of Business Development at DWL, where he managed a team that built partnerships with Accenture, Oracle, Tata Consulting, Wipro, Cognizant and IBM. Steve designed the channel and strategy that ultimately culminated in the acquisition of DWL by IBM in 2005. He went on to lead a global team within IBM that was responsible for major system integrator partnerships. In 2008, he left IBM to found a niche consulting firm focused on business development for SaaS organizations. Steve holds a BA in anthropology and sociology from Carleton University in Ottawa.
Ellie Wheeler
Ellie Wheeler is a Partner at Greycroft and is based in the firm’s New York office. Prior to joining Greycroft, Ellie worked in a similar role evaluating investment opportunities at Lowercase Capital. Ellie also worked at Cisco in Corporate Development doing acquisitions, investments, and strategy within the unified communications, enterprise software, mobile, and video sectors. While at Cisco, she was involved in multiple acquisitions and investments, including PostPath, Jabber, Xobni, and Tandberg. She began her career in growth capital private equity at Summit Partners in Boston. Ellie graduated magna cum laude from Georgetown University with a BA in Psychology and holds an MBA from Harvard Business School.
Glenn McGonnigle
Glenn McGonnigle is a General Partner at TechOperators. Prior to launching TechOperators in 2008, Glenn was CEO of VistaScape Security Systems, a venture-backed provider of enterprise intelligent video surveillance software. He lead the company through its successful sale to Siemens Building Technologies. Previously, Glenn was a co-founder and senior executive of Atlanta-based Internet Security Systems (ISS) where he helped raise initial venture capital and launch the business. For 7 years, he led the business development team in developing sales channels and entering the managed security services market. During his tenure, the company grew from startup to revenues of over $225 million and was later acquired by IBM for $1.3 billion.
Brendan Hannigan
Brendan joined Polaris Partners in 2016 as an entrepreneur partner. In this role, he focuses on funding and founding companies in the technology sector with a concentration in cloud, analytics, and cybersecurity. Brendan is a co-founder of Sonrai Security and chairman of Twistlock, both Polaris investments. He also currently serves on the board of Bitsight Technologies and Flashpoint. A 25 year technology industry veteran, Brendan was most recently the general manager of IBM Security. Under Brendan’s leadership, IBM Security grew significantly faster than the overall security market to become the number one enterprise security provider in the world with almost $2B of annual revenue.
Matt Devost
Currently, Devost serves as CEO & Co-Founder of OODA LLC as well as a review board member for Black Hat. In 2010, he co-founded the cybersecurity consultancy FusionX LLC which was acquired by Accenture in August 2015, where he went on to lead Accenture's Global Cyber Defense practice. Devost also founded the Terrorism Research Center in 1996 where he served as President and CEO until November 2008 and held founding or leadership roles at iDefense, iSIGHT Partners, Total Intel, SDI, Tulco Holdings, and Technical Defense.
image/svg+xml image/svg+xml
Flashpoint Acquires Vulnerability Intelligence Leader Risk Based Security

The WireX Botnet: How Industry Collaboration Disrupted a DDoS Attack

August 25, 2017


On August 17th, 2017, multiple Content Delivery Networks (CDNs) and content providers were subject to significant attacks from a botnet dubbed WireX. The botnet is named for an anagram for one of the delimiter strings in its command and control protocol. The WireX botnet comprises primarily Android devices running malicious applications and is designed to create DDoS traffic. The botnet is sometimes associated with ransom notes to targets.

A few days ago, Google was alerted that this malware was available on its Play Store. Shortly following the notification, Google removed hundreds of affected applications and started the process to remove the applications from all devices.

Researchers from Akamai, Cloudflare, Flashpoint, Google, Oracle Dyn, RiskIQ, Team Cymru, and other organizations cooperated to combat this botnet. Evidence indicates that the botnet may have been active as early as August 2nd, but it was the attacks on August 17th that drew the attention of these organizations. This post represents the combined knowledge and efforts of the researchers working to share information about a botnet in the best interest of the internet community as a whole. This blog post was written together by researchers from numerous organizations and released concurrently by Akamai, Cloudflare, Flashpoint, and RiskIQ.

Attack details

The first available indicators of the WireX botnet appeared on August 2nd as minor attacks that went unnoticed at the time. It wasn’t discovered until researchers began searching for the 26 character User-Agent string in logs. These initial attacks were minimal and suggest that the malware was in development or in the early stages of deployment. More prolonged attacks have been identified starting on August 15th, with some events sourced from a minimum of 70,000 concurrent IP addresses, as shown in Figure 1.

WireX is a volumetric DDoS attack at the application layer. The traffic generated by the attack nodes is primarily HTTP GET requests, though some variants appears to be capable of issuing POST requests. In other words, the botnet produces traffic resembling valid requests from generic HTTP clients and web browsers.

Figure 1: Estimated growth of the botnet based on the count of unique IPs per hour observed participating in attacks.
Figure 1: Estimated growth of the botnet based on the count of unique IPs per hour observed participating in attacks.

During initial observation, the majority of the traffic from this botnet was distinguished by the use of an HTTP Request’s User-Agent string containing the lowercase English alphabet characters, in random order.

Some of the User-Agent values seen:

User-Agent: jigpuzbcomkenhvladtwysqfxr

User-Agent: yudjmikcvzoqwsbflghtxpanre

User-Agent: mckvhaflwzbderiysoguxnqtpj

User-Agent: deogjvtynmcxzwfsbahirukqpl

User-Agent: fdmjczoeyarnuqkbgtlivsxhwp

User-Agent: yczfxlrenuqtwmavhojpigkdsb

User-Agent: dnlseufokcgvmajqzpbtrwyxih

Variants of the malware have also been observed emitting User-Agent strings of varying length and expanded character sets, sometimes including common browser User-Agents. Here are some samples of other User-Agents observed:

User-Agent: xlw2ibhqg0i

User-Agent: bg5pdrxhka2sjr1g

User-Agent: 5z5z39iit9damit5czrxf655ok060d544ytvx25g19hcg18jpo8vk3q

User-Agent: fge26sd5e1vnyp3bdmc6ie0

User-Agent: m8al87qi9z5cqlwc8mb7ug85g47u

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 (.NET CLR 3.5.30729)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20071018 BonEcho/

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_5_7; en-us) AppleWebKit/530.19.2 (KHTML, like Gecko) Version/4.0.2

Tracing the nodes

Analysis of the incoming attack data for the August 17th attack revealed that devices from more than 100 countries participated, an uncharacteristic trait for current botnets. The distribution of the attacking IPs along with the distinctive User-Agent string led the researchers who began the initial investigation to believe that other organizations may have seen or would be likely to experience similar attacks. The researchers reached out to peers in other organizations for verification of what they were seeing.

Once the larger collaborative effort began, the investigation began to unfold rapidly starting with the investigation of historic log information, which revealed a connection between the attacking IPs and something malicious, possibly running on top of the Android operating system.

In the wake of the Mirai attacks, information sharing groups have seen a resurgence, where researchers share situation reports and, when necessary, collaborate to solve Internet-wide problems. Further, WannaCry, Petya and other global events have only strengthened the value of this collaboration. Many information sharing groups, such as this one, are purely informal communications amongst peers across the industry.

Finding the software

Investigation of the logs from attacks on August 17th revealed previous attacks meeting the same signature implicated the first Android application, “”. Researchers quickly grabbed examples of the application to understand how it works and determine if related applications might exist. Searches using variations of the application name and parameters in the application bundle revealed multiple additional applications from the same, or similarly named authors, with comparable descriptions, as shown in Figure 2. As new applications were located, others on the team began to dig into the binaries to learn how they worked.

Figure 2: A screenshot of one of the searches for similar malware.
Figure 2: A screenshot of one of the searches for similar malware.

There were few cases where these applications were found in well known and pre-configured app stores for mobile devices. Whenever possible, the abuse teams for these app stores, like Google, were contacted and worked expediently to remove the offending content. Google provided the following comment in response to this research:

We identified approximately 300 apps associated with the issue, blocked them from the Play Store, and we’re in the process of removing them from all affected devices. The researchers’ findings, combined with our own analysis, have enabled us to better protect Android users, everywhere.

Malware overview

Many of the identified applications fell into the categories of media/video players, ringtones or tools such as storage managers and app stores with additional hidden features that were not readily apparent to the end users that were infected. At the launch of the applications, the nefarious components begin their work by starting the command and control polling service which queries the command and control server, most commonly, for attack commands. When attack commands are received, the parsing service inspects the raw attack command, parses it and invokes the attacking service with the extracted parameters.

The applications that housed these attack functions, while malicious, appeared to be benign to the users who had installed them. These applications also took advantage of features of the Android service architecture allowing applications to use system resources, even while in the background, and are thus able to launch attacks when the application is not in use. Antivirus scanners currently recognize this malware as the “Android Clicker” trojan, but this campaign’s purpose has nothing to do with click fraud. It is likely that this malware used to be related to click fraud, but was repurposed for DDoS.

An in-depth overview of the internals of the rogue components of the applications can be found in Appendix 1.


These discoveries were only possible due to open collaboration between DDoS targets, DDoS mitigation companies, and intelligence firms. Every player had a different piece of the puzzle; without contributions from everyone, this botnet would have remained a mystery.

The best thing that organizations can do when under a DDoS attack is to share detailed metrics related to the attack. With this information, those of us who are empowered to dismantle these schemes can learn much more about them than would otherwise be possible.

These metrics include packet captures, lists of attacking IP addresses, ransom notes, request headers, and any patterns of interest. Such data should not contain any legitimate client traffic, to reduce privacy concerns and also because legitimate traffic can pollute and slow down analysis. And most importantly, give permission to share this data—not only to your vendors, but to their trusted contacts in the broader security community who may have expertise or visibility not available in your own circle of vendors.

There is no shame in asking for help. Not only is there no shame, but in most cases it is impossible to hide the fact that you are under a DDoS attack. A number of research efforts have the ability to detect the existence of DDoS attacks happening globally against third parties no matter how much those parties want to keep the issue quiet. There are few benefits to being secretive and numerous benefits to being forthcoming.

Sharing detailed attack metrics also allows for both formal and informal information sharing groups to communicate about and understand the attacks that are happening at a global scale, rather than simply what they see on their own platforms. This report is an example of how informal sharing can have a dramatically positive impact for the victims and the Internet as a whole. Cross-organizational cooperation is essential to combat threats to the Internet and, without it, criminal schemes can operate without examination.

We would like to acknowledge and thank the researchers at Akamai, Cloudflare, Flashpoint, Google, RiskIQ, Team Cymru, and other organizations not publicly listed. We would also like to thank the FBI for their assistance in this matter.

Authors & Researchers

• Tim April : Senior Security Architect, Akamai
• Chris Baker : Principal of Threat Intelligence, Oracle Dyn
• Matt Carothers
• Jaime Cochran : Security Analyst, Cloudflare
• Marek Majkowski : Enthusiastic Geek, Cloudflare
• Jared Mauch : Internetworking Research and Architecture, Akamai
• Allison Nixon : Director of Security Research, Flashpoint
• Justin Paine : Head Of Trust & Safety, Cloudflare
• Chad Seaman : Sen. Security Intelligence Response Team Engineer, Akamai SIRT
• Darren Spruell : Threat Researcher, RiskIQ
• Zach Wikholm : Research Developer, Flashpoint
• And others

Appendix A: Analysis of the Malware

Identifying C2 Domains

Inspection of various decompiled applications revealed multiple sub-domains of a single root domain ( that were suspected of being a part of the command and control (C2) infrastructure for the botnet.

$ grep http * -R

com/twdlphqg/app/ExplorationActivity.smali:  const-string v3, “”

com/twdlphqg/app/services/Ryiidrxcjmfb.smali:  const-string v1, “”

The first domain ( did not return content; it simply returned an empty response with a 200 OK status code and appeared to be used for basic Internet connectivity testing.

The second domain ( appeared to be linked to the DDoS components of the malware. The component of the application referencing this domain was responsible for creating an Android Service equipped with two WebView instances. The first WebView instance serves as the C2 beacon, polling the C2 server for attack directives. The second serves as a reference to clone WebView objects for attacking. This component also contains the basic logic for spinning up and configuring these attacking instances.

There are multiple other interesting components in play here, all with unique roles. The first component types discussed here serve as the basic, always-on, persistent execution mechanisms. Some applications utilized Service objects instantiated using the android/os/Handler->postDelayed functionality. This essentially causes the app to persist via a Service that polls the C2 server on a regular interval — even while the application is backgrounded. Other variations of the application utilized AsyncTask objects in attempts to achieve the same goal.

The second component is a WebViewClient that serves as the C2 attack directive parser. It is responsible for detecting onPageFinished events from the C2 WebView instance being controlled by the polling service and parsing whatever command is returned. When an attack command is successfully parsed, this component is responsible for calling the function that ultimately launches the attack traffic.

Overview of Components

Below we’ll cover the relevant pieces individually, using pseudo code based on knowledge gathered from the decompiled APK(s). We’ll then talk about what the pseudo code is doing in more detail as it relates to attack commands and techniques.

Service Runner

The ServiceRunner component’s role is a means of persistent background execution by injecting the Runnable object type into a timed OS Handler. Because of the nature of a Service in Android environments, the malware can continue to keep running once the app has been launched and placed in the background. Execution will only stop if application is actively killed/closed by the mobile device user or in the event of a device restart.

Service Runner Pseudo Code

Class ServiceRunner extends Object {

  Public function run() {




C2 Response Parser

The AttackCommandParser serves as the callback that is triggered when the C2 WebView detects that a page load has occurred. The parser loads the page’s content and extracts the <title> body as the attack command. Based on observed samples, a payload from the C2 looks like this: 






Figure 3: Attack Directive Sample

The value extracted from the <title> tag is then tested via String->contains() to ensure it contains the value token delimiter snewxwri. If the delimiter is found, the content is trimmed of leading or trailing whitespace and then split() into an Array of pieces on the delimiter. The resulting tokens are then used as parameters to be passed to the DDoS_Service->attack()method.

C2 Response Parser Pseudo Code

Class AttackCommandParser extends WebViewClient {

  Public function onPageFinished(C2_WebView,C2_url) {

    String pageTitle = C2_WebView->getTitle();

    if (pageTitle->contains(“snewxwri”) == true) {

      pageTitle = pageTitle->trim();

      Array commandParts = pageTitle.split(“snewxwri”);

      String target = commandParts[0];

      String userAgent = commandParts[1];

      String referer = commandParts[2];

      DDoS_Service->attack(target, userAgent, referer);




DDoS Service

The DDoS_Service component is what runs the show. It has 3 core functions. These responsibilities are to get the Service up and running, provide the poll_c2() method for loading the C2 WebView, and most importantly — launching attacks. We’ll look at these responsibilities one at a time after presenting the pseudo code.

DDoS Service Pseudo Code

Class DDoS_Service extends Object {

  Public function onCreate() {

    Handler OS_Handler = new Handler();

    Object Runner = new ServiceRunner();



  Public function poll_c2() {

    WebViewClient C2_Parser = new AttackCommandParser();

    WebView C2_WebView = new WebView();

    WebViewSettings C2_WebView_Settings = C2_WebView->getSettings();







  Public function attack(String target, String userAgent, String referer) {

    HashMap WebViewHeaders = new HashMap();



   WebView[] AttackerViews = new WebView[100];

    for (int i=0; i<AttackerViews.length; i++) {

      AttackerViews[i] = new WebView();




      WebViewSettings AttackWebViewSettings = AttackerViews[i]->getSettings();










DDoS Service onCreate()

The onCreate() method is straightforward: it creates a new android/os/Handler and ServiceRunner instance. The ServiceRunner instance is then hooked into the Handler via a call to postDelayed(). According to Android documentation, this “Causes the Runnable r to be added to the message queue, to be run after the specified amount of time elapses.” The second parameter to this method call is the number of milliseconds before the Runnable is invoked. In this sample that value is 2, which is a very aggressive timing strategy.

DDoS Service poll_c2()

The poll_c2() method is responsible for continually reloading the WebView with the C2 URL while also hooking the AttackCommandParser WebViewClient into the poller WebView instance. Before polling the C2 domains, the service will clear and disable the cache as well as clear the WebView instance history. These steps are performed to ensure that the client is always getting up-to-date information from the C2 and not being served cache hits from the local device. We’ll see this tactic reused during the analysis of the attack() method as well.

DDoS Service attack()

Public function attack(String target, String userAgent, String referer) {

  HashMap WebViewHeaders = new HashMap();



  WebView[] AttackerViews = new WebView[100];

  for (int i=0; i<AttackerViews.length; i++) {

    AttackerViews[i] = new WebView();




    WebViewSettings AttackWebViewSettings = AttackerViews[i]->getSettings();









The attack() method is responsible for generating the actual attack traffic. The AttackCommandParser->onPageFinished() that was previously discussed will pass in the target, userAgent, and referer values that were handed out by the last C2 interaction. This method will create a HashMap object that will configure the HTTP Headers used during the attack.

The first header is the HTTP Referer, which as we know was supplied by the C2 server. In all observed cases, this value was a mirror value of the actual target. The second header is the X-Requested-With header; although the WebView would usually have a default value, it is overwritten with a blank value. Typically this header coming from an embedded WebView would contain information about the Android application such as com.[app_author].app. It’s likely that this Header was blanked specifically to obfuscate who or what was generating the attack traffic that would be seen by the target.

Once the headers are configured, an empty Array of WebView place holders is instantiated, followed by a loop to fill this Array with actual WebView instances.  Each instance goes through the same set of configuration processes. The WebView instances created will have their history, saved form data, and cache cleared. The JavaScript capabilities are enabled (this is typically disabled by default for embedded WebViews), the User-Agent string that will be present in the HTTP Headers is overwritten with the value supplied by the C2 attack directive, and the CacheMode set to LOAD_NO_CACHE, which will force the browser instance to bypass local caches and fetch the target URL for each request.

In a final attempt to ensure that no cache hits will occur on the device and a that request will be sent to the target, the application also deletes its local webview.db and webviewCache.db files from the device before loading each request.

Finally we see the loadUrl() method is called on the newly configured WebView instance using the target URL and customized WebViewHeaders HashMap.

Running the Malware-User Experience

While many of the identified apps had already been removed from the Google Play store, mirrors remained online from which we could download the APK files. We loaded “twdlphqg” (one of the attacking apps) onto a freshly-reset physical Samsung Galaxy S4 that had been running Lollipop and security patches from 2015.

This app, along with the others we tested, used innocuous-sounding names like “Device Analysis”, “Data Storage” “Package Manager”, and so forth.

When the app is run, it appears to be a very basic ringtone app. Only three ringtones are provided. The app can play and set ringtones but has no other functionality.

In the background, this app spawns additional processes that continue to run even while the phone’s screen is locked. This allows the app to launch DDoS attacks from the phone in the background. When we left the phone on a charger and let it go to sleep, it continued to launch DDoS attacks.

Notably, it is no longer possible to install this application as Google’s PlayProtect feature now blocks this app from being installed. Google is also removing it from devices that already have it installed. All of the applications we tested that were part of this campaign produced this block message; disabling PlayProtect was necessary to run the malware.

Ring Ring! DDoS! – Variations in Malicious Apps

We tested multiple applications from this campaign. There were different variations in behavior and user interface and they weren’t all ringtone apps. All tests were conducted on the same phone.


Xryufrix was the top hitter from the DDoS statistics, but when run, its performance was underwhelming. It’s possible there was a compatibility issue preventing it from reaching its full DDoS potential. This app asked for fewer permissions upon initial install, but did ask for the same lock screen related device administrator permissions as twdlphqg. This one pretended to be a YouTube app. When it first opens, it queries the axclick domain for the DDoS attack commands as well as a GET request against p[.]axclick[.]store/?utm_source=tfikztteuic, which returns the Play Store URL of a different app located at market://details?id=com[.]luckybooster[.]app . When the user attempts to play a Youtube video, this app closes, deletes its icon from the app list, and makes itself impossible to execute afterwards, which is possibly the result of a crash. It also opens the Play store download link for the “Luckybooster” app, which did not DDoS when it was run. The xryufrix app does not launch DDoS attacks while the phone is asleep nor does it launch DDoS attacks at any time other than when the app is active.




Flashpoint Intelligence Brief

Subscribe to our newsletter to stay up-to-date on our latest research, news, and events