As someone who has been working on enterprise digital stacks for over 12 years and building analytics stacks for over 7 years, I’ve broken my fair-share of client websites with malformed javascript.
It happens to pretty much every analytics professional *on accident* at semi-regular intervals — but there are very few organizations that have teams trying to take down the data layer on a daily basis *on purpose* – an Advertising & Analytics Red Team.
When was the last time you heard about an Analytics & Advertising Red Team attacking a data layer and finding a zero-day data supply attribution vulnerabilities?
Has your organization mapped their attribution vulnerabilities or attempted to map Javascript errors across all your digital assets and channels? Which javascript errors are developer errors and which are something else?
Does your organization have any business relationships that are “Pay per conversion?” Or any sort of financial commitments that rely on the accuracy of javascript tracking? Do you rely on 3rd party tools for attribution reconciliation like Shopify’s Google Analytics integration that can be broken and hijacked via hardcoded scripts?
Have you ever had an advertising firm tell you that they will guarantee XXX% ROI with a YY% profit-sharing on that ROI and “we’ll take nothing if we make nothing?” Did you deploy *their javascript* on *your website*?
Does your business know if people are messing with your data layer? Has your team ever found someone trying to “Hide their ass” behind a proxy while trying to manipulate your data layer with fake events?
The screen shot below is from Facebook’s new “Manage Traffic Permissions” blocker available in the “Pixel” area of a Facebook ads account… a useful new tool for stopping data from entering an account via their pixels:
There are hundreds of thousands of small, medium and large businesses that get into “We don’t get paid if you don’t get paid” digital ROI contracts without being experts in javascript attribution manipulation to confirm they aren’t being hoodwinked by a sophisticated attribution fraud manipulation.
I like to compare advertising attribution fraud via javascript manipulation to someone who is paying for a contractor to build a house, while getting hoodwinked into buying a money pit. The client buying the house could monitor the exact cost of everything being purchased, and confirm everyone working on the house were experts, and also be shown a finished house that appears to be perfect, but still be purchasing a complete lemon with enormous problems hidden behind the walls and floors.
Basically, if you don’t know “what makes a good house” then it’s hard to determine if a clean veneer is hiding trouble. As I thought more about advertising attribution fraud, I realized that more people just needed to understand the digital-housing equivalents to “Why we use grounded outlets” and “Why we don’t use lead pipes anymore” — simple scenarios that not only explain threats to be aware of, but also the exposure if vulnerabilities are ignored.
Without further adieu, i’m going to be explaining in some public posts different strategies for Analytics & Advertising Red Teams — and some tactics to look out for if you build the attribution reports for a business — tips for the Advertising & Analytics Blue Team, if you will…
Analytics & Advertising Red Team: Attribution Attacks via Facebook’s “fbclid” Parameter
Imagine an attacker wants to convince a business to stop buying Facebook ads “because they aren’t profitable” even though the campaigns *are* profitable.
How could this be done?
Are you watching for a “Slow-Drip DDOS” with Facebook’s “fbclid” Parameter (61 Character Strings) to Reduce the Conversion Rate on a UTM-Reconciliation-Based Analytics Infrastructure?
On Facebook, when a user clicks an ad and leaves Facebook, they are eventually given the “Destination URL” which is provided by the client buying the ads, along with a URL parameter that Facebook appends called “fbclid” – this is what a final-resolved-URL would look like after a user clicks on a Facebook ad:
https://www.[domain].com/[page-name]/?utm_source=facebook&utm_medium=ppc&utm_campaign=spring-facebook&fbclid=IwAR1T521XWiX8888888S7MULOFbJZwq4W6wK_5555556YTbr0QTo26462648
Now how would an attacker take advantage of this?
An attacker could slowly send requests to certain pages.. a “slow-drip DDOS” if you will. The attacker would craft the DDOS attack to use the UTM parameters (utm_source, utm_medium, utm_campaign) from an advertising campaign and dynamically change the fbclid for each request (and potentially change other details of the requests too).
Now… this is *not an attack on Facebook* (details below) but instead, it could be an attack targeting Mixpanel data, or Google Analytics data, or any 3rd party analytics system that wouldn’t have access to Facebook’s “fbclid reconciliation tool” which basically helps Facebook prevent advertising fraud.
Basically… Facebook can tell if you spoof the “fbclid” and won’t inflate their internal Facebook data that is shared with the advertiser, but nearly every other analytics platform would consider each of these unique requests/URls “a unique person” because that’s how it normally works…so you use Facebook’s unique URL parameter against the other analytics networks…
This process to slowly send lots of requests to an advertising destination URL would probably have some *very minor* impact on Facebook’s 1st party analytics if the DDOS were distributed (*but* probably almost no impact on Facebook’s advertising reports because the fbclid must match with an actual user who clicked on the ad for that page-view/conversion to be tracked within Facebook’s native ads interface)… essentially this is *not* an attack on Facebook per-say, although you’re using Facebook’s URL parameter as the weapon against an additional 3rd party analytics tool like Google Analytics.
This concept to use one advertising network against another network should be considered a common tactic by malicious data supply operators — their goal is to take money from one ad network or one publisher, and push it into their own network — you’ve gotta look to adversarial data supply tactics to understand those players.
What happens after a Slow Drip DDOS attack against a “Data-Driven Company”?
After a slow-drip DDOS targeted to a specific UTM campaign was completed, If your team was tracking the conversion rate of the traffic from that advertising campaign, they would see an artificially-low conversion rate. And a subtle DDOS, with only 5-10% of the total traffic going to those UTM parameters, could potentially be missed. An attribution expert would maybe look in Facebook and see X data, and then look in Google Analytics/Mixpanel and see Y data, and assume that the UTM tracking was more accurate than Facebook’s pixel.
There is a moment in any type of data supply attack where one analytics system was likely accurate — if you layer fraud detection and different analytics/advertising pixels into your architecture, oftentimes one of them will have detected the bot or the odd behavior — but the reconciliation process is where you either detect the aberrant data, or double down on a bad decision.
Now.. how could this be used against your organization?
Imagine you run a very large company with 10,000 unique SKUs — and 50 of your products are in direct competition to another unscrupulous company.
In this scenario, your competitor *does not want you to market these 50 products* and through a simple page visit –> product feed retargeting campaign they are able to identify 100% of your UTM URL structures for the retargeting ads for those 50 products.
That company then calculates the traffic they get on their own product pages, does a little math, and sends 23,600 bot visits to those unique product pages using your Facebook UTM parameters over a 6-month period, a slow and steady drip that would be missed in an active campaign.
After 6 months, the massive corporation reviews the conversion rate of all their products and stops buying retargeting ads for products with the lowest conversion rates… and the 50 products targeted in the small DDOS have now been removed from Facebook retargeting budgets — not due to the data in Facebook (which would still remain pretty accurate) — but due to the analytics professionals using a separate 3rd party analytics tool to track their conversion rates across platforms.
The lesson?: if an attacker knows what tool your team uses for attribution reconciliation, it makes it much easier to attack the data collection methods for that tool or process. If your team “doesn’t trust Facebook” and refuses to believe the data in that system, that lack of understanding about UTM attribution fraud could come back to bite them…
The Analytics & Advertising Blue Team Lesson? Don’t Ignore Attribution Discrepancies.
Always audit your pixels and double check data in native platforms. If anyone on your team says, “I don’t trust Facebook’s data here” or “X app always inflates our data, we rely on Y app” – those are big red flags. That means there is an attribution discrepancy that is either a technical deployment problem, a high-level data architecture problem, or some type of attribution manipulation (either accidental or deliberate).
Also, if your team finds problems, bots or inflated data, you should be helping decision makers understand what would have happened *if you didn’t discover the problem.* Could the organization have nearly made a “data-driven-into-a-ditch decision?” Did the blue team just block a targeted UTM-botnet that was trying to impact ROI calculations?
It’s important for these types of unique attribution-protection “wins” to be celebrated, studied, and shared with more team members.
The Analytics & Advertising Blue Team is the front-lines of an organization trying to make data-driven decisions, and any strong digital organization should know and feel confident in their ability to handle red team data supply attacks.
Do you know of any wild data supply or attribution attacks? Share them with me on Twitter @thezedwards or via email and i’ll try to include them in a future write-up…
Recent Comments