This series of posts recounts how, in November 2016, we hunted for and took down Gooligan, the infamous Android OAuth stealing botnet. What makes Gooligan special is its weaponization of OAuth tokens, something that was never observed in mainstream crimeware before. At its peak, Gooligan had hijacked over 1M OAuth tokens in an attempt to perform fraudulent Play store installs and reviews.
Gooligan marks a turning point in Android malware evolution as the first large scale OAuth crimeware
While I rarely talk publicly about it, a key function of our research team is to assist product teams when they face major attacks. Gooligan’s very public nature and the extensive cross-industry collaboration around its takedown provided the perfect opportunity to shed some light on this aspect of our mission.
Being part of the emergency response task force is a central aspect of our team, as it allows us to focus on helping our users when they need it the most and exposes us to tough challenges in real time, as they occur. Overcoming these challenges fuels our understanding of the security and abuse landscape. Quite a few of our most successful research projects started due to these escalations, including our work on fake phone verified accounts, the study of HTTPS interception, and the analysis of mail delivery security.
Given the complexity of this subject, I broke it down into three posts to ensure that I can provide a a full debrief of what went down and cover all the major aspects of the Gooligan escalation. This first post recounts the Gooligan origin story and offers an overview of how Gooligan works. The second post provides an in-depth analysis of Gooligan’s inner workings and an analysis of its network infrastructure. The final post discusses Gooligan various monetization schemas and its takedown.
This series of posts is modeled after the talk I gave with Oren Koriat from Check Point, at Botconf in December 2017, on the subject. Here is a re-recording of the talk:
You can get the slides here but they are pretty bare.
As OAuth token abuse is Gooligan’s key innovation, let’s start by quickly summarizing how OAuth tokens work, so it is clear why this is such a game changer.
What are Oauth tokens?
OAuth tokens are the de facto standard for granting apps and devices restricted access to online accounts without sharing passwords and with a limited set of privileges. For example, you can use an OAuth token to only allow an app to read your Twitter timeline, while preventing it from changing your settings or posting on your behalf.
Under the hood, the service provides the app, on your behalf, with an OAuth token that is tied to the exact privileges you want to grant. In a way that is similar but not exactly the same, when you sign up with your Google account on an Android device, Google gives the device a token that allows it to access Google services on your behalf. This is the long term token that Gooligan stole in order to impersonate users on the Play Store. You can read more about Android long term tokens here.
Overview
Overall, Gooligan is made of six key components:
- Repackaged app: This is the initial payload, which is usually a popular repackaged app that was weaponized. This APK embedded a secondary hidden/encrypted payload.
- Registration server: Record device information when it join the botnet after being rooted.
- Exploit server: The exploit server is the system that will deliver the exact exploit needed to root the device, based on the information provided by the secondary payload. Having the device information is essential, as Kingroot only targeted unpatched older devices (4.x and below). The post-rooting process is also responsible for backdooring the phone recovery process to enable persistence.
- Fraudulent app and ads C&C: This infrastructure is responsible for collecting exfiltrated data and telling the malware which (non-Google related) ads to display and which Play store app to boost.
- Play Store app module: This is an injected library that allows the malware to issue commands to the Play store through the Play store app. This complex process was set up in an attempt to avoid triggering Play store protection.
- Ads fraud module: This is a module that would regularly display ads to the users as an overlay. The ads were benign and came from an ad company that we couldn’t identify.
Genesis
Analyzing Gooligan’s code allowed us to trace it back to earlier malware families, as it built upon their codebase. While those families are clearly related code-wise, we can’t ascertain whether the same actor is behind all of them, because a lot of the shared features were extensively discussed in Chinese blogs.
SnapPea the precursor
As visible in the timeline above, Gooligan’s genesis can be traced back to the SnapPea adware that emerged in March 2015 and was discovered by Check Point in July of the same year. SnapPea’s key innovation was the weaponization of the exploit kit Kingroot, which was until then used by enthusiasts to root their phones and install custom ROMs.
SnapPea Kingroot straightforward weaponization led to a rather unusual infection vector: its authors resorted to backdooring the backup application SnapPea to be able to infect victims. After an Android device was physically connected to an infected PC, the malicious SnapPea application used Kingroot to root the device in order to install malware on the device. Gooligan is related to SnapPea because Gooligan also use Kingroot exploits to root devices but in an untethered way via a custom remote server.
Following SnapPea footsteps Gooligan weaponizes the Kingroot exploits to root old unpatched Android devices.
Ghost Push the role model
A few months after SnapPea appeared, Cheetah Mobile uncovered Ghost Push, which quickly became one of the largest Android (off-market) botnets. What set Ghost Push apart technically from SnapPea was the addition of code that allowed it to persist during the device reset. This persistence was accomplished by patching, among other things, the recovery script located in the system partition after Ghost Push gained root access in the same way Snappea did. Gooligan reused the same persistent code.
Wrap-up
As outline in this post Gooligan is a complex malware that built on previous malware generation and extend it to a brand new vector of attack: OAuth tokens theft.
Gooligan marks a turning point in Android malware evolution as the first large scale OAuth crimeware
Building up on this post, the next one of the serie will provide in-depth analysis of Gooligan’s inner workings and an analysis of its network infrastructure. The final post will discusses Gooligan various monetization schemas and its takedown
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 Twitter, Facebook, Google+, or LinkedIn. You can also get the full posts directly in your inbox by subscribing to the mailing list or via RSS.
A bientôt!
