Inside 'Master134': More ad networks tied to malvertising campaign

AdKernel's denials

We spoke with AdKernel executives frequently over the course of several months. Initially, the company presented a clear and consistent version of events. AdKernel slammed the Check Point report on several fronts -- the first of which was the researchers' description of the ad tech company's business model.

[Malvertising arrangements are like] an incredibly complex version of Russian nesting dolls. The main ad network may not even know about the bad publishers and bad advertisers right away.

"Specifically, we are not now and have never been a reseller or ad network, as the article suggests," Judy Shapiro, chief strategy advisor at AdKernel, wrote in a statement to SearchSecurity. She clarified that AdKernel is a white-label ad-serving technology company to ad networks and resellers. The company provides ad-serving tools, including real-time bidding tools, analytics, optimization algorithms and other products.

To be sure, AdKernel's website clearly states it provides ad-serving technology to publishers and online ad networks. More importantly, Check Point's original report attributed two key redirection domains -- xml.bikinisgroup.com and xml.junnify.com -- to AdKernel. The Junnify and BikinisGroup homepages both feature a "Powered by AdKernel" link, but AdKernel denied owning the sites and said the domains were owned by two of its clients, which are also ad network companies.

"The unequivocal answer is no -- we have never owned or operated these sites in any way," the company said in a follow-up statement sent to SearchSecurity on July 31.

AdKernel said it couldn't provide "confidential client information" about the owners of the sites. Both domains had privacy policies that claimed Junnify and BikinisGroup were "registered companies," though this was not the case; AdKernel said the names were "aliases" for the actual ad networks, which the company initially declined to name.

The company also said the xml.bikinisgroup.com and xml.junnify.com domains were "relatively new" and that the company's monitoring team detected issues with the sites two weeks prior to Check Point's report's publication. "Our team was investigating these issues when the Check Point report came out," the statement read.

Check Point Research didn't contact any of the advertising companies named in the Master134 report prior to its publication. Instead, researchers spoke with several consultants in the online ad tech industry to learn about the companies implicated in the report. It was those discussions that gave the Check Point Research team confidence in naming all five companies in the report, explained Lotem Finkelsteen, Check Point's threat intelligence analysis team leader and one of the contributors to the Master134 report.

"We decided not to contact them before publishing because we didn't believe there was any chance their behavior would change [until after the report was public]," he said. "Before the report came out, we felt they had no incentive to change."

Finkelsteen said his team reviewed AdKernel's case and its request to amend the report, which resulted in the removal of all references to AdKernel. "Initially, we decided to include AdKernel in the report and attribute the domains to them because those websites were being powered by AdKernel services," he said in August 2018. "They told us they didn't own the domains and weren't reselling the traffic [from Master134], and we decided to give them the benefit of the doubt."

AdKernel repeatedly denied it operated the junnify.com and bikinisgroup.com domains. The company insisted it is dedicated to cybersecurity and fights Malvertising and ad fraud on the web with several procedures, including blocked bad IP addresses and malicious domains as well as pattern matching for suspicious URLs. Shapiro also noted that engagement marketing firm EngageSimply, a "sister company" to AdKernel of which she is the CEO, recently unveiled a new endeavor with AdKernel called The Trust Web to bring authentication and verification to the online ad ecosystem using digital certificates (AdKernel CEO Yevgen "Eugene" Peresvyetov is CTO of EngageSimply).

Through several conversations and email messages, Shapiro and Peresvyetov discussed the proliferation of bad advertisers and publishers in the online advertising industry. Peresvyetov said its ad network clients' low pricing "attracts lots of people who are trying to deceive ad networks and buy cheaper clicks and distribute their malware."

These arrangements, Shapiro said, are like "an incredibly complex version of Russian nesting dolls. The main ad network may not even know about the bad publishers and bad advertisers right away."

Despite AdKernel's concerns about malicious actors and its expressed commitment to rid them from its platform, SearchSecurity discovered the very activity its executives described occurred right under AdKernel's nose.

Connecting the dots

At first glance, there's no public information about who owns the Junnify and BikinisGroup domains. Most WhoIs lookups and related searches for the domains don't produce any information that connect them to AdKernel; ICANN's WhoIs search, for example, points to domain privacy services such as WhoisGuard Inc. and Domains By Proxy LLC.

You may also have cases where there are as many 30 intermediaries sitting between the advertisers and their publishers.

However, SearchSecurity discovered evidence that did connect AdKernel to the domains. Robtex results for xml.bikinisgroup.com and xml.junnify.com show the domains have CNAMES (yeesshh.xml.ak-is.net and junnify.xml.ak-is.net, respectively) that list AdKernel LLC under their WhoIs info.

Paul Vixie, DNS pioneer and CEO of Farsight Security, explained that Robtex results appear to include Referral WhoIs (RWhoIs) information relating to both AdKernel and its ISP, Webair Internet Development Inc. in Garden City, N.Y. (Webair is also the ISP for Adsterra and AdventureFeeds, two other companies cited in Check Point Research's Master134 report.) RWhoIs is a sister protocol to WhoIs that includes a hierarchy of referral services.

Robtex isn't the only service to connect AdKernel with these suspicious domains. Vixie used the AbuseIPDB service to search the xml.bikinisgroup.com domain and its related IP address. The results also included data from the American Registry for Internet Numbers, which showed a referral from Webair for a block of IP addresses (198.134.116.0/24) to AdKernel LLC in New York.

Vixie explained why an ISP would have this kind of referral in its WhoIs data.

"If somebody in that block misbehaves, there's a chance that a lawsuit will bypass Webair and go straight to AdKernel," Vixie said. "This is a transparency function that's meant to cut down on the ISP's time spent answering complaints."

Vixie strefssed that such referrals are not uncommon with ISPs, and Webair's decision doesn't "represent any prior knowledge about the ethics of this customers."

AdKernel had an explanation for the RWhoIs and Robtex results. While the company was initially adamant that it didn't operate the domains in any way, AdKernel confirmed in December that the data was accurate. Shapiro said the RWhoIs data points to AdKernel because the company serves as the webhost. Even though AdKernel provides the ad-serving platform for the domains, the company said it doesn't actually manage the sites.

AdKernel explained in a statement that the two XML domains serve as self-service portals for both publishers and advertisers to register and log into the ad networks, with an XML feed that displays their ads. The company also sent a diagram detailing the arrangement with the two domains, citing "Client 1" and "Client 2" as the owners of xm.bikinisgroup.com and xml.junnify.com domains, respectively. AdKernel claims "bad advertisers" on those client sites were to blame, not the ad networks.

Meanwhile, Check Point maintains that the domains were used to buy and then resell the WordPress traffic to the exploit kit domains.

"All ads for all ad networks that use white-label ad serving are served using these service endpoints (in this case, xml.bikinisgroup.com)," AdKernel wrote in the statement. "This is standard industry practice. These alias domains are not consumer-facing content sites."

AdKernel is correct, according to the Trustworthy Accountability Group (TAG), an organization focused on reducing ad fraud and criminal activity in the digital advertising industry. Rachel Thomas, COO of TAG, said it's not at all uncommon to have intermediaries like white-label ad-serving companies partner with multiple ad networks. Many of these intermediaries resell traffic or provide ad-hosting services.

"Usually, you can have five or 10 of these intermediaries in a given advertising deal," Thomas said, "but you may also have cases where there are as many 30 intermediaries sitting between the advertisers and their publishers."

While many of those complex arrangements are legitimate, Thomas said, some are not, and the complexities and layers of intermediaries can be abused by threat actors posing as legitimate companies that use the online ad ecosystem to engage in click fraud and malvertising.

AdKernel insists it falls in the legitimate category.

"These domains are owned by the [ad] networks and pointed to the AdKernel IP address via CNAME records, much like any online webhosting arrangement (AWS, Bluehost, etc.)," the company said. "That is why you see the owner of the IP as AdKernel. We do not own or manage any publisher sites or advertiser sites. We provide the specialized ad-hosting services required to process over 200 billion requests per day in an efficient manner."

However, white-label ad-serving firms aren't absolved of their responsibilities and an ad serving should be aware of suspicious activity on the ad network it hosts, TAG's Thomas said.

Check Point's Finkelsteen agreed that as the webhost, AdKernel would have had a significant amount of network data to monitor and inspect for suspicious activity.

"This is very interesting because it means they do have access to this data, or at least they know who purchased the [hosting] service," Finkelsteen said. "They should have visibility -- and technically speaking, they probably do have visibility."

Finkelsteen added that AdKernel's AWS comparison isn't quite appropriate.

"If Amazon found out there was some malicious activity that was being hosted on their servers, they would take it offline immediately," he said. "AdKernel, however, doesn't really seem to mind even when the information is being reported to it. If it did, why didn't they take them down?"

Did we mess up by not catching that malware? Yes we did. Did we learn the lesson? Yes we did. Was it the result of criminal collusion? Absolutely not. The ecosystem is complex and has its holes and they do get exploited.

Peresvyetov said the "bad optics" of the situation sent AdKernel into "panic mode" when the Check Point report was published. "Our clients panicked, we panicked," he wrote in an email. "The clients decided to shut down those domains."

Peresvyetov said the bad actors involved in Master134 were not his clients and that AdKernel did everything it could to stop the malicious activity.

"When the [Check Point] report came out, we immediately investigated what happened, found bad campaign and shut it down, as well as the traffic from those domains," he wrote. "It was an ad campaign, which was created by bad actors using self-service interface and employed advanced masking technique to avoid detection of its true nature."

AdKernel couldn't provide evidence to support its claim that a rogue ad campaign on two separate sites was to blame for the Master134 activity, not the ad network clients themselves. Peresvyetov couldn't explain why AdKernel and the clients simply didn't disclose that they had successfully identified and stopped the malicious activity last summer.

"Did we mess up by not catching that malware?" he wrote. "Yes we did. Did we learn the lesson? Yes we did. Was it the result of criminal collusion? Absolutely not. The ecosystem is complex and has its holes and they do get exploited."

AdKernel declined to name the clients who owned the bikinisgroup and junnify domains or provide any information about the alleged "bad campaign" operating on those sites, leaving the question of who was responsible for malicious activity on the domains unanswered.

Additional advertising firms in the chain

Despite AdKernel's refusal to say who its ad network clients were, SearchSecurity found information pertaining to the identities of the companies. For example, the xml.bikinisgroup.com domain is a CNAME to another URL, yeesshh.xml.ak-is.net, which was also associated with AdKernel, according to Robtex results. In addition to the bikinisgroup and junnify domains, Check Point's Finkelsteen said yeesshh.com was on the research team's radar. "Those three are the sites directly related to Master134," he said.

Bikinisgroup.com's privacy policy page, Finkelsteen said, also has an admin contact email that uses the yeesshh.com domain. While Junnify and BikinisGroup look like generic, cut-and-paste ad sites, yeesshh.com is a different story. Yeesshh Ltd. is a digital advertising company based in Barcelona, Spain, that describes itself as a "redirect traffic provider."

Junnify's contact email, meanwhile, goes to a different address: [email protected].

"Explorads.com doesn't exist," Finkelsteen said, "but explorads.media.com is a slightly more legit-looking company."

ExplorAds Ltd., headquartered in Cyprus, identifies as an advertising network. The company's website had grammatical errors and misspellings (though ExplorAds recently redesigned its website and corrected some of these errors). And like other online advertising firms in this malvertising investigation, ExplorAds has been cited for suspicious activity before; the explorads.com domain, for example, is blocked by Malwarebytes for "being involved in fraud and for hosting PUPs," while other companies have connected the xml.explorads.com domain to adware schemes.

Yeesshh had also been flagged for suspicious activity, with the company's xml.yeesshh.com domain earning the scorn of some infosec organizations over forced browser redirections.

In addition to the email addresses, data from URLscan.io shows the effective URL for the bikinisgroup domain is login.yeesshh.com, while WebsiteInformer.com attributes xml.bikinisgroup.com and xml.junnify.com to Yeessh and ExplorAds, respectively.

On Dec. 10, SearchSecurity contacted Yeesshh and ExplorAds to inquire about the AbuseIPDB and Robtex data that connected their companies with the bikinisgroup and junnify domains. The domains were taken down shortly thereafter.

AdKernel said Client 1 and Client 2 were responsible for the domain removals and said the timing of the two takedowns was likely "coincidental" to any communications SearchSecurity had with AdKernel, Yeesshh or ExplorAds. Shapiro said her company had "no visibility" into why clients add or remove sites on AdKernel's network.

Shapiro said she wasn't surprised the sites were removed in December following the damaging Check Point report, despite the fact that the report was published on July 28 and references to the two domains were removed from the report on August 1. "These ad networks going down do not mean they were bad, but the Check Point report resulted in no one willing to buy traffic on their network so they could not survive," she said.

Still, AdKernel asserted that two separate clients -- with whom AdKernel had no direct communication following the Master134 report -- both took down their domains at approximately the same time, several months after the publication of the report.

After numerous interviews with AdKernel, the company admitted in February that Yeesshh and ExplorAds were, in fact, the third-party network clients, aka Client 1 and Client 2. Revising their earlier statements, Peresvyetov said AdKernel has worked with ExplorAds and Yeesh for "many years" and began hosting the junnify and bikinisgroup domains in 2017. He also insisted ExplorAds was a reputable firm and dismissed the company's history of red flags.

"To the best of my knowledge, they did not have 'bad behavior,'" Peresvyetov wrote. "Occasional reports about ad-serving URLs happen because [from] time to time, ad networks have bad actors (bad publishers or malvertisers) abusing their media buying/selling activities."

Peresvyetov also insisted neither Yeesshh nor ExplorAds was responsible for the Master134 activity that occurred on the two domains. Instead, he claimed Check Point's research was flawed.

"The [WordPress] traffic did not come from the single IP 134.249.116.78," he wrote. "The report shows simplified picture of the traffic flow, so it seems that all traffic from hacked sites went to malicious campaigns. It's not true."

When pressed for proof of his claims, Peresvyetov submitted only a marked up version of Check Point's own diagram detailing the Master134 campaign. He put SearchSecurity in contact with ExplorAds Co-Founder Raz Butbika, who echoed Peresvyetov's claims about the removal of the domains.

"Unfortunately, in December, one of the networks used their XML feed to run malicious ads on our traffic without our permission and against our will, which eventually hurt our good name," she said. "We immediately removed and banned that offer from our platform. In order to not damage our reputation, we decided to change the domain."

AdKernel and ExplorAds, however, couldn't provide any technical evidence of such an attack on the domain and couldn't offer any details or information about how they collectively stopped the Master134 activity last summer.

Butbika clarified that the alleged December incident involved different publishers/advertisers than the Master134 activity in July and said there is no connection between the two incidents.

In a follow-up interview, SearchSecurity challenged Peresvyetov on the inconsistencies and shifts with AdKernel's version of events. Why did the company claim it found issues with the bikinisgroup and junnify domains prior to the Check Point report and then later walk back that claim? Why did the company claim the domains were "relatively new" when in fact they had hosted the sites since 2017? Why did AdKernel say it didn't operate the domains in any way when it was hosting those sites?

Peresvyetov attributed those inconsistencies to miscommunications and partially blamed Shapiro for the confusion. Peresvyetov, however, was copied on several of the company statements Shapiro emailed to SearchSecurity, including all of the statements with the above discrepancies.

Why did ExplorAds and Yeesshh set up ad network sites through AdKernel with different company names that purported to be entirely separate companies? Neither ExplorAds or Yeesshh offered an explanation, but Peresvyetov said when threat actors abuse ad networks, the activity "takes a toll" on the networks' domains; as a result, they often create new domains that are separate from "brand name domain names that are storefronts for companies."

AdKernel, Yeesshh and ExplorAds were asked to provide technical information that would support their version of events which could be reviewed by third-party security experts. Peresvyetov said that "unless it's a court order or law enforcement agency request," he needed the clients' permission to release that information.

ExplorAds' Butbika declined to share any details about the December incident or the Master134 activity last summer.

Jean-christophe Petit, managing partner at Yeesshh, declined to comment.

"Yeesshh is not mentioned in this [Check Point Research report]," he wrote in an email. "I cannot help you further."

Peresvyetov said AdKernel and its clients had data that he believed would clear his company as well as ExplorAds and Yeesshh of any wrongdoing in the Master134 campaign. As of press time, none of the companies had delivered that information.

Read part four of our six-part series on the Master134 campaign and malvertising threats.