Taking down Gooligan part 3 — monetization and clean-up

This post provides an in-depth analysis of Gooligan monetization schemas and recounts how Google took it down with the help of external partners.

This post is the final post of the series dedicated to the hunt and take down of Gooligan that we did at Google in collaboration with Check Point in November 2016. The
first post
recounts the Gooligan origin story and offers an overview of how it works. The
second one
provides an in-depth analysis of Gooligan’s inner workings and an analysis of its network infrastructure. As this post builds on the previous two, I encourage you to read them if you haven’t done so already.

This series of posts is modeled after the talk I gave on the subject at Botconf in December 2017. Here is a recording of the talk:

You can also get the slides
, but they are pretty bare.


Gooligan’s goal was to monetize the infected devices through two main fraudulent schemas: Ad fraud and Android app boosting.

Ad fraud

Gooligan Fraudulent ads pop up

As shown in the screenshot above, periodically Gooligan will use its root privileges to overlay an ad popup for a legitimate app on top of any activity the user was currently doing. Under the hood, Gooligan knows when the user is looking at the phone, as it monitors various key events, including when the screen is turned on.

We don’t have much insight on how effective those ad campaigns were or who was reselling them, as they don’t abuse Google’s ads network, and they use a gazillion HTTP redirects, which makes attribution close to impossible. However we believe that ad fraud was the main driver of Gooligan revenue, given its volume and the fact that we blocked its fake installs as discussed below.

App Boosting

The second way Gooligan attempted to monetize infected devices was by performing Android app boosting. An app boosting package is a bundle of searches for a specific query on the Play store, followed by an install and a review. The search is used in an attempt to rank the app for a given term. This tactic is commonly peddled in App Store Optimization (ASO) guides.

Example of Play Store boosting service

The reason Gooligan went through the trouble of stealing OAuth tokens and manipulating the Play store is probably that the defenses we put in place are very effective at detecting and discounting fake synthetic installs. Using real devices with real accounts was the Gooligan authors’ attempt to evade our detection systems. Overall, it was a total failure on their side: We caught all the fake installs, and suspended the abusive apps and developers.

Play Store Fraud Diagram

As illustrated in the diagram above, the app boosting was done in four steps:

  1. Token stealing: The malware extracts the phone’s long term token from the phone’s accounts.

  2. Taking order: Gooligan reports phone information to the central command and control system, and receives in response a reply telling it which app to boost, including which search term to use and which comment to leave (if any). Phone information is exfiltrated because Gooligan authors also had access to non-compromised phones and were trying to use information obtained from Gooligan to fake requests from those phones.

  3. Token exchange: The long term token is exchanged for a short term token that allows Gooligan to access the Play store. We are positive that no user data was compromised by Gooligan, as no other data was ever requested by Gooligan.

  4. Boosting: The fake search, installation, and potential review is carried out through the manipulated Play store app.


Cleaning up Gooligan was challenging for two reasons: First, as discussed in the
infection post
, its reset persistence mechanism meant that doing a factory reset was not enough to clean up the old unpatched devices. Second, the Oauth tokens had been exfiltrated to Gooligan servers.

Asking users to reflash their devices would have been unreasonable and issuing an OTA (Over The Air) update would have take too long. Given this difficult context and the need to act quickly to protect our users we went for an alternative solution that we rarely use: orchestrating a takedown with the help of third parties.


Gooligan sinkhole efficiency chart

With the help of Shadowserver foundation and domain registrars we sinkholed Gooligan domains and got them to point to Shadowserver controlled IPs instead of IPs controlled by Gooligan authors. This sinkholing ensured that infected devices couldn’t exfiltrate token or receive fraud commands, as they would connect to sinkhole servers instead of the real command and control servers. As shown in the graph above, our takedown was very successful: It blocked over 50M attempts to connect to Gooligan’s control server in 2017.


Example of Notifications sent to Gooligan victims

With the sinkhole in place, the second part of the remediation involved resecuring the accounts that were compromised, by disabling the exfiltrated tokens and notifying the users. Notification at that scale is very complex, for three key reasons:

  • Reaching users in a timely fashion across a wide range of devices is difficult. We ended up using a combination of SMS, email, and Android messaging, depending on what communication channel was available.

  • It was important to make the notification understandable and useful to all users. Explaining what was happening clearly and simply took a lot of iteration. We ended up with the notification shown in the screenshot above.

  • Once crafted, the text of the notification and help page had to be translated into the languages spoken by our users. Performing high quality internationalization for over 20 languages very quickly was quite a feat.


Overall, in order to respond to Gooligan, many people, including myself, ended up working long hours through the Thanksgiving weekend (an important holiday in the U.S.). Our commitment to quickly eradicate this threat paid off: On the evening of Monday, November 29th, the takedown took place, followed the next day by the resecuring of the compromised accounts.
All in all, this takedown took a mere few days, which is blazing fast when you compare it to other similar ones. For example, the
Avalanche botnet
) takedown took four years of intensive efforts.

To conclude, Gooligan was a very challenging malware to tackle, due to its scale and unconventional tactics. We were able to meet this challenge and defeat it, thanks to a cross-industry effort and the involvement of many teams at Google that didn’t go home until users were safe.

Thanks for reading this post all the way to the end. I hope it showcases how we approach botnet fighting and sheds some light on some of the lesser known, yet still critical, activities that our research team assists with.

Thank you for reading this post till the end! If you enjoyed it, don’t forget to share it on your favorite social network so that your friends and colleagues can enjoy it too and learn about Gooligan.

To get notified when my next post is online, follow me on
, or
. You can also get the full posts directly in your inbox by subscribing to the mailing list or via

A bientôt!

*** This is a Security Bloggers Network syndicated blog from Elie on Internet Security and Performance authored by Elie Bursztein. Read the original post at: https://www.elie.net/blog/security/taking-down-gooligan-a-retrospective-analysis-part-3-monetization-and-clean-up?utm_source=rss