Social Engineering with Google Analytics
September 25, 2016
A few weeks back I logged into my Google Analytics account and noticed some strange hits from domains such as ‘free-traffic.xyz’, ‘social-buttons-ii.xyz’, and ‘eu-cookie-law-enforcement2.xyz’. Obviously these were spam and not legitimate traffic. However, I began to ponder how this traffic was being generated and how it could be used for evil. If a sophisticated attacker could flood a victim’s Google Analytics portal with referrals from a domain the attacker controls, a victim may investigate the referrals and browse to the attacker controlled domain. Sneaky! The rest of this blog post will cover the Development and a User-Guide of a Social Engineering Toolkit (SET) module I wrote called “Google Analytics Attack”.
Development
At the time, all I knew about Google Analytics was what I had learned from setting it up on a few sites. Whilst setting up Google Analytics, I was assigned a unique tracking ID (UA-XXXXX) and then was instructed to post some provided JavaScript into all the web pages I wanted to be tracked. When a user visits a webpage being tracked, the JavaScript would collect some information and then ship it off to Google’s server with my tracking ID. If I wanted to generate this sort of traffic, I had two options. I could either automate a web browser with fake details and allow the provided JavaScript to handle the requests to Google’s server, or I could figure out how the JavaScript was making the request and generate them myself. The latter option seemed far more feasible and simple. Luckily, Google did a great job documenting how to make these requests, so I didn’t have to fiddle around with reversing the provided JavaScript. This was the documentation I found:
- https://developers.google.com/analytics/devguides/collection/protocol/v1/reference
- https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters
I quickly learned that spoofed tracking data could be sent directly to Google with a simple GET request, like shown below:
|
1 2 3 |
GET /collect?payload_data HTTP/1.1 Host: https://www.google-analytics.com User-Agent: user_agent_string |
The minimal payload data needed to simulate a page view is as follows:
| Name | Parameter | Example | Description |
|---|---|---|---|
| Protocol Version | v | v=1 | The protocol version. The value should be 1. |
| Tracking ID | tid | tid=UA-123456-1 | The ID that distinguishes to which Google Analytics property to send data. |
| Client ID | cid | cid=xxxxx | An ID unique to a particular user. |
| Hit Type | t | t=pageview | The type of interaction collected for a particular user. |
| Client ID | cid | cid=555 | This anonymously identifies a particular user, device, or browser instance. |
| Document Path | dp | dp=/aboutme | The path portion of the page URL. Should begin with ‘/’. |
| Document Host Name | dh | dh=http://xyz.com | Specifies the hostname from which content was hosted. |
| Document Title | dt | dt=About | The title of the page / document. |
In addition, I needed to figure out how to specify a referral, so that I could populate it with my attacker controlled domain. I found the referral parameter in the documentation, as well as an additional interesting parameter.:
| Name | Parameter | Example | Description |
|---|---|---|---|
| Document Referrer | dr | dr=http://fakedomain.com/ | Specifies which referral source brought traffic to a website. |
| Anonymize IP | aip | aip=1 | When present, the IP address of the sender will be anonymized. |
I could now specify a referral, as well as tell Google to anonymize my IP address (not sure what that actually does, but it sounded nice). I quickly put it all together, opened BurpSuite, and fired off a request. The request and response can be seen below. As well as a my Google Analytics account showing a spoofed referral.
With a working PoC, it was time to weaponize it to make it useful for penetration testing and Red Teaming. It seemed most fitting within the Social Engineering Toolkit (SET), so I decided to write it as a “Third Party Module”. SET is written in Python, so it was pretty straight forward. Most of the needed parameters can be derived programmatically with a single request to the target webpage. So I wanted to have an “automatic” mode, in addition to just manually enter the parameters. I learned along the way that it is important to randomize the Client ID (cid) parameter. This makes it seem like each referral is a new visitor, otherwise Google Analytics would think the same person was being referred over and over. Keep reading to see what the module ended up looking like! The module can be found on my GitHub.
User-Guide
Note: “Google Analytics Attack” should only used for educational or research purposes. Do not use the tool against systems without proper permission.
Installation
To install the script, first change your working directory to that of the setoolkit’s installation. On Kali Linux, this can be done with the following command:
|
1 |
cd /usr/share/set |
Once here, we need to pull down the module and place it in the “modules” directory.
|
1 |
wget https://raw.githubusercontent.com/ZonkSec/google-analytics-attack/master/google_analytics_attack.py -P modules/ |
Lastly, we need to make sure the dependencies are installed. The only 3rd part dependeny is the “requests” module, which can be installed like so:
|
1 |
pip install requests |
Thats it! “Google Analytics Attack” should now be up and running.
Usage
To run “Google Analytics Attack”, simply start setoolkit and select “Third Party Modules”, which is option 3. From here select “Google Analytics Attack by @ZonkSec”.
“Google Analytics Attack” has two modes: automatic and manual. The automatic mode will streamline the spoofing process by making a request to the target webpage and then pulling out all the needed parameters. While the manual mode can be used to manually enter the parameters needed. See the tables above for more information on each parameter.
After the parameters have been generated by one of the two modes, the module can print the parameters to screen before sending the spoof. If the parameters are not correct, cancel the module by hitting CTRL+C and restart. If the parameters are correct, press ENTER and the module will send the payload to the Google Analytics service.
The last option within “Google Analytics Attack” is the loop functionality. This will repeatedly send the payload. This is useful for when you want to flood a victims Google Analytics UI . The more “referrals” that are sent, the higher the spoofed referer will be within the Google Analytics UI. This increases the likelihood of an admin browsing to your domain. To loop, simply enter “y” when prompted, then enter the number of seconds to delay between each request. Use CTRL+C to stop the loop.
That’s it! You are now able to spoof traffic to the Google Analytics service. The last step in the attack is setup some sort of exploit on your “referal” domain. This can be done within the “Social-Engineering Attacks > Website Attack Vectors” menu within the Social Engineering Toolkit. My favorite is to clone the Google Analytics login page for credential harvesting. 🙂
Thanks for reading!