Despite a public pledge of "zero tolerance" for malicious activity, a digital ad network previously tied to major malvertising campaigns was still connecting to a malicious IP address involved in traffic hijacking.
Adsterra, an ad network based in Cyprus, was implicated in an extensive malvertising campaign discovered by Check Point Software Technologies in 2018. Adsterra claimed to have blocked the malicious activity and improved its defenses, but a SearchSecurity investigation discovered the ad network continued connecting to a malicious server used in the campaign as recently as last month.
The campaign originally began with a party, dubbed "Master134" by Check Point researchers, posing as a legitimate publisher on Adsterra's ad network platform. Master134 used more than 10,000 compromised WordPress sites to redirect visitors to a malicious sever in Ukraine with the IP address 18.104.22.168. The hijacked traffic was sold on Adsterra's RTB platform to other ad networks, where it was sold to other networks before being sold yet again to threat actors running several well-known malicious sites and exploit kits.
In Check Point's report, researchers described Adsterra as "infamous" and said the ad network had a direct relationship with "Master134" by paying the threat actor for the hijacked traffic. Lotem Finkelsteen, Check Point's threat intelligence analysis team leader and co-author of the report, told SearchSecurity that Adsterra either knew it was accepting hijacked traffic or chose to ignore the signs.
Adsterra responded to the report with a blog post titled "Zero Tolerance for Illegal Traffic Sources," in which the company denied the allegations that it was knowingly involved with Master134. The company also blamed other third-party ad networks, even though Check Point reported Adsterra received the traffic directly from Master134's IP address.
"[W]e would like to emphasize that we do not accept traffic from hacked/hijacked sites. We have zero tolerance for illegal traffic sources," the statement read. "All publishers' accounts that were mentioned in that article have been suspended. Malware ads are prohibited in Adsterra Network and we have a monitor system that checks all campaigns and stops all suspicious activity."
Despite the denials and the supposed actions taken by Adsterra, a SearchSecurity investigation found the ad network was still connecting to the 22.214.171.124 IP address as recently as last month. When confronted with this information, Adsterra offered a series of explanations that called into question the company's efforts to prevent malvertising and ad fraud.
Open source intelligence tools revealed the 126.96.36.199 IP address, which is still active, was connecting to ecpms.net, a redirection domain owned and operated by Adsterra, during July and August of this year.
SearchSecurity emailed Adsterra in August about the domain's connection to the Master134 IP address and received a reply from the company's support team, which said the Adsterra policy team would investigation the issue. The email also said the company "considers the [Master134] case closed."
We sent a follow-up email to Adsterra asking for more information about how it bans malicious accounts and what steps the company takes to prevent repeat offenders from abusing Adsterra's self-service platform.
Adsterra Support Team
"When we 'ban an account' in our system we block the account and all payments associated with that account. We also block all ads being displayed to that account," the support team wrote. "We investigate all incoming reports on illegal activities on our network and do our best to prevent them from happening. We utilize special software (both in-house and 3rd party) to scan and monitor ads and traffic 24/7. Furthermore, after the incident with 'Master134' we have purchased additional 3rd party software to scan our feed, but you should understand that it is always a cat-mouse game when it comes to catching a 'bad actor'."
SearchSecurity also asked Adsterra about the allegations that the ad network was knowingly accepting traffic from malicious sources like Master134. "We serve hundreds of millions of ad impressions per day and we don't need any illegal traffic because our advertisers simply won't accept it and pay for it," the support team wrote.
While the ecpms.net's connections to Master134 appeared to end following the conversation with Adsterra's support team, SearchSecurity discovered a second domain owned by the company, 7fkm2r4pzi.com, was also connecting to the malicious IP address. According to RiskIQ's Passive Total Community Edition, the connections from 188.8.131.52 to the domain began in August shortly after the connections to ecpms.net ceased.
SearchSecurity emailed Adsterra again several times about the second domain, but the company did not respond initially. We then reached out to the ad network's official Twitter account and asked why the Adsterra domains were still connecting to the Master134 server. In a Twitter exchange, Adsterra said the Master134 threat actors set up a new account, which was also banned. The ad network also said it "blacklisted all traffic with this IP in referrer header."
"They'll think twice before sending traffic to our network after no payment," Adsterra said.
We asked why Adsterra hadn't taken the step of banning the IP address last year following Check Point's Master134 and the resulting press coverage, especially since the company said it had "zero tolerance" for such activity.
"Since the publisher's account was banned without a payout and they removed our link shortly after, we considered they understood their traffic is not welcome here. It took them a while to sign up again," Adsterra tweeted. "Please also note that blacklisting this IP in a referrer header does not give 100% protection -- a portion of traffic can be redirected with no referrer. However, we admit this could have been done before as a precaution. Thus, we have updated our internal policies accordingly."
Adsterra said the malicious account didn't received its payment due, but the company couldn't say whether or not the fraudulent accounts operated by Master134 had ever received payment from the company.
SearchSecurity requested more information about the accounts and the steps Adsterra took to stop the malicious activity on its websites. The ad network responded with information similar to what it previously tweeted but did not address those questions directly.
"The executive team has been notified of this issue," Adsterra support team wrote. "However, we find this case closed and the new account has been banned as well."
According to RiskIQ's PassiveTotal, the connections from Master134 to the 7fkm2r4pzi.com domain ended on Sept. 14, the same day as the above email. Adsterra hasn't responded to further requests from SearchSecurity.
Adsterra's prevention methods questioned
Security vendors in the ad fraud and malvertising prevention market said Adsterra's method of blacklisting the IP address is a largely useless approach and that stronger measures are needed to stop threat actors like Master134.
Hagai Shechter, CEO of Fraudlogix, an ad fraud prevention vendor based in Hallandale Beach, Fla., said restricting IP addresses via HTTP headers isn't effective because -- as Adsterra itself pointed out -- threat actors can remove malicious IP addresses from their headers and make HTTP requests with "no-referrer." In addition, Schechter said public blacklists, even if implemented effectively at the firewall level, are often outdated.
"It's rare to find a publicly available IP blacklist list that's going to be recent and that will have the good stuff in there," he said.
It's also unclear why Adsterra's additional investment in ad security and new scanners didn't prevent the Master134 IP address from repeatedly connecting to the ad network's domains, given the address was known to be malicious. According to a July blog post titled "We Keep You Safe," Adsterra said it felt "bound to take action" and announced it had added a second ad security scanner from a vendor called AdSecure to further reduce fraud and malvertising.
However, AdSecure was launched in 2017 by a company called ExoGroup, based in Barcelona. ExoGroup is also the parent company of ad network ExoClick that, like Adsterra, was implicated in the Master134 campaign in 2018, as well as previous malvertising campaigns. According to AdSecure's website, the company's "partners" include several ad networks including ExoClick, Adsterra and AdKernel, which was also connected to the Master134 campaign.
SearchSecurity reached out to AdSecure to learn more about how its flagship product worked and its relationship to ExoClick and the other ad networks. The company did not respond. [UPDATE: Adsecure emailed a statement to SearchSecurity the day after this article was published. The statement is contained below.]
SearchSecurity spoke with GeoEdge, the other ad security vendor used by Adsterra, which declined to address the ad network directly. GeoEdge CEO Amnon Siev said that in general, some ad network clients choose to essentially ignore the alerts that GeoEdge provides about malicious activity and allow suspicious traffic and IP addresses on their platforms.
Schechter agreed and said clients have full control over how they use Fraudlogix's products and some simply choose to look the other way when it comes to signs of click fraud and malvertising.
"That absolutely happens," he said. "The fuel for the industry is volume. If Google blocks out 10% of their ad traffic, they can still survive, but when you're a smaller network, that 10% could be the difference between staying in business or not."
Siev added that he believes AdSecure isn't an effective solution for preventing ad fraud and malvertising. "I've never tested their solution," he said, "but I know from talking to customers that have switched from them to us what gaps are there."
He also criticized AdSecure's connection to ExoClick. "We continue to flag many of [ExoClick's] campaigns," Siev said. "They've pushed back on us and say there's no malicious activity in their campaigns."
In a statement sent to SearchSecurity on Nov. 1, Adsecure sales manager Bryan Taylor wrote "AdSecure is a reporting tool, what clients do with those reports and the measures they implement to prevent fraudulent actors is their decision.
AdSecure is part of Exogroup and is born out of the experience that ExoClick has dealing with advertising fraud. ExoClick has been fighting advertising fraud since 2006 and has used the services of GeoEdge and others over the years. Unfortunately, most of these companies rely on outdated technology and they have proven inefficient to detect many types of fraud, especially the most recent ones, such as push lockers. This triggered Exogroup to invest into the development of a new technology, that would address the wide scope of issues that plague the online advertising ecosystem today," Taylor wrote.
There is no silver bullet to address the issue of malvertising. And there is no such thing as 100% safe. There is a very good reason why people setup an alarm system in their home. But even then, some more ambitious criminals might still break a window and give it a go. Do platforms and networks have issues with malicious activity? Yes, absolutely. And GeoEdge, RiskIQ, AdSecure or any others would not exist if that was not the case," Taylor added. "If we refer to your quote from Amnon Siev, he admits himself "I've never tested their solution" so we don't think this even deserves a response. What matters to us are the results that the partners get from AdSecure, and the hundreds of malvertising issues that we prevent on a daily basis. And all of the companies fighting this fight are good companies to have on the market."
It's unclear if other Adsterra domains are connecting to Master134; the 184.108.40.206 IP address connects to thousands of domains, including a litany of WordPress sites as well as several ad network platforms, and Adsterra owns and operates a significant number of domains. For example, MyIP.ms, an online database of websites and IP addresses, shows more than 400 domains owned by Ad Market Limited, the corporate name of Adsterra.