KAI uncovers fake traffic being purchased by major DSPs and SSPs
READ THE PRESS RELEASE – Kubient Discovers New “Weasel” Injection Ad Fraud Scheme and Announces Public Availability of KAI Proprietary Pre-Bid AI
KAI uncovers fake traffic being purchased by major DSPs and SSPs
In Shakespeare’s Henry IV, the king famously complains that the people in his court “commit the oldest sins the newest kinds of ways.”
In advertising the same is true: the technology powering this massive industry continues to improve, and with each new technology, a new fraud comes from it.
Since 2019, we have seen a massive increase in PreBid.js being used to run secondary auctions within display ad units. While some companies defend this behavior by claiming they provide content in the ad unit as well as ads, others use it in far more nefarious ways. One such egregious use of this tactic is being done by a company called Wease.IM (http://wease.im).
Our KAI fraud prevention team, while working with a partner of ours, discovered that numerous major SSPs, DSPs and Brands have been purchasing traffic from Wease.IM. These include Index Exchange, PubMatic, Sovrn, Verizon Media, Improve Digital, The Trade Desk, Amazon.com, Adobe, Outbrain, Sephora and others. All have bought and served impressions for Wease.IM traffic as recently as September 14th. The fraud committed was very simple and effective, and despite seeing other fraud prevention vendors’ prebid wrappers existing in the calls, none of them prevented the sale of the traffic. This fraud shows the limits of not only prebid fraud prevention, but also ads.txt and sellers.json.
Wease.IM is a Windows desktop application and is found only via the microsoft windows store. It has no installable binary you can download; it is only accessible to Windows 10 users from the Windows 10 store.
It bills itself as a privacy messenger and provides stock image screenshots of the application, all utilizing the same sample screen of the application:
Our team installed and tested the Wease.IM application, inside a controlled environment using Windows 10. On initial launch this is what we found:
Upon initial load we notice a Outstream Video Ad unit appears. No ads rendered in our test on Wease.IM but we noticed OutBrain ads rendered in the banner slots at the top and side of the application.
After closing the Outstream Video Ad Unit we attempted to add a contact to test the chat communication feature.
The contact feature did not find the users we searched for but we were able to eventually communicate with another member of our team on the application. However the application was very buggy and definitely did not feel like it would be used by a large amount of users.
We ran our test multiple times and the results were the same. It was clear the app itself was not a fully functioning application. Which then begged the question: why did so many Ads.txt entries exist for them?
We found they had accounts at Outbrain, AOL (Verizon), Yahoo (Verizon), AvantisVideo, Improve Digital, DistrictM, SmartyAds, Sovrn, OpenX, Index Exchange, Smart Ad Server, and RhythmOne. Those accounts furthered authorized reselling to PulsePoint, Pubmatic, SpotXchange, Teads, Rubicon Project, AppNexus (Xandr), Google, and many others.
Despite not having a functioning application and no ads on their website, Wease.IM was selling a decent volume of traffic through the above platforms.
Through further analysis, we determined that Wease.IM is associated with Mobideck.net, a French focused advertising company with 4 employees listed on LinkedIn. In fact, many of the Wease.IM ads.txt entries were under Mobideck.net. We believe strongly that Mobideck owns and controls Wease.IM. Wease.IM itself has no employees listed on LinkedIn. To further back our conclusion, we discovered both domains have their DNS from Gandi.net and both use the same hosting company PoneyTelecom (more on them later).
With this information, we began digging in further with our partner to understand how Wease.IM was selling and running ads from a non functioning app, and how it was circumventing traditional fraud prevention measures.
Our partner also had a Desktop application that served ads. While capturing and reviewing their behavior, we noticed that ad calls would change as coming from their app to coming from Wease.IM/Mobideck.net—despite our partner having no relationship with either.
An example call being made to IndexExchange shows this behavior:
Encoded URL
Decoded URL
https://as-sec.casalemedia.com/cygnus?s=375437&v=7.2&r={“id”:”202147d1aad180d58″,”imp”:[{“id”:”2033b2aeac9de2e04″,”ext”:{“siteID”:”375437″,”sid”:”300×250″},”banner”:{“w”:300,”h”:250,”topframe”:1}}],”site”:{“ref”:”http://www.wease.im/”,“page”:”https://www.wease.im/?utm_source=display&utm_medium=cpc&utm_campaign=1711&utm_term=0.67514614667666-US-mrect-158282-3.3757307333833-unknown-3cdce9c52fd64dd697b51f24495c5a76-smart-10-default2-Cable/DSL-5-10-unknown-useast.rtb.mobideck.net-1599767235&utm_content=1599767398573″},”ext”:{“source”:”prebid”},”regs”:{“ext”:{“gdpr”:1}},”user”:{“ext”:{“consent”:”CO4f-ZWO5h7v6B7ACBENA2CsAP_AAP_AAChQGeNf_X_fb2vj-_599_t0eY1f9_63v-wzjheNs-8NyZ_X_L4Xv2MyvB36pq4KuR4ku3bBAQdtHOncTQmRwIlVqTLsbk2Mr7NKJ7LEmlsbe2dYGH9vn8XT_ZKZ70_v___7_3______777-QM8a_-v–3tfH9_z77_bo8xq_7_1vf9hnHC8bZ94bkz-v-XwvfsZleDv1TVwVcjxJdu2CAg7aOdO4mhMjgRKrUmXY3JsZX2aUT2WJNLY29s6wMP7fP4un-yUz3p_f___3_v______3338gAA.YAAAAAAAAAAAAAAAAAA”}}}&ac=j&sd=1
Immediately what stands out is the source of the call is PreBid, which we discovered was PreBid JS and led us to what unraveled the whole setup.
Mobideck utilized a SSP/DSP and in a few tests we noticed the Mobideck code came through winning bids of Pubmatic, but we expect they are utilizing more than a single SSP to place their code. What they did was very simple; they would create an HTML compatible ad unit inside an iframe from their domain `wease.im` which would inject PreBid JS scripts, that were numerous versions behind the current one, and they would load them from a private CDN called Bunny CDN.
The prebid_stats2.0.4.js is a custom code developed by Wease.IM/Mobideck that is used to alter or handle PreBid.JS event calls with prebuilt listeners to catch PreBid.js Requests. It hard codes many values to obfuscate the true location of the iframe.
The ad unit then creates an empty div called `ad-container`.
Then a lot of custom code occurs to manipulate the PreBid JS, including an auto refresh setting to continue making new ad calls every 60 seconds.
Then the code begins its auctions to many of the partners who Wease.IM has accounts with.
And after this point it follows a normal PreBid.JS procedure, except it is now selling the inventory from our partner’s application as if it came from Wease.IM. Because there are multiple nested iframes before the ads are placed, the prebid wrappers by fraud prevention companies are unable to see that the requests came from a different app, and from our test even allowed ads to show when run through JSFiddle on the web. This can be tested here and seen in screenshots below:
In essence, Mobideck employed a bait and switch tactic: they pitched their application to SSPs and Exchanges, provided fake numbers in terms of users and engagement (since it was a Windows 10 app and not a website, verification of such was more difficult and easily spoofed). Then once they got the SSPs and Exchanges to approve them, they used a malicious ad unit to purchase traffic from legitimate Windows 10 Applications and resold it as their own at a higher markup.
The immediate red flag to all of this was the use of PoneyTelecom (mentioned earlier). They are a hosting system that allows spammers and hackers to utilize their service with little to no repercussion (see here, here and here).
A quick IP scan of the referring domain would allow any system to notice all the IPs were from PoneyTelecom CIDRs.
- 62.210.0.0/16
- 195.154.0.0/16
- 212.129.0.0/18
- 62.4.0.0/19
- 212.83.128.0/19
- 212.83.160.0/19
- 212.47.224.0/19
- 163.172.0.0/16
- 51.15.0.0/16
- 151.115.0.0/16
- 51.158.0.0/15
- 2001:bc8::/32
We expect these IP ranges are associated with more than just this particular attack, and recommend all advertising platforms to block them.
The gaps of PreBid.JS, Ads.TXT and Sellers.json are all too apparent here. Wease.IM had a proper ads.txt, the Sellers.json entries matched the ads.txt, and all other scanners detected the ad unit as coming from Wease.im and all those systems combined viewed the traffic as legitimate. Wease.IM is not the first nor will it be the last that manipulate PreBid.JS to mask inventory and deceive detection systems.
Our recommendation to all publishers that are out there is to monitor your properties and immediately request any advertisers who inject PreBid.js into your ad units to be blocked. Only allow buyers to purchase your inventory through your own PreBid.JS, or similar technology. We recommend the industry take a hard stance on PreBid.JS resellers and block or ban any such company who engages in it.
