As more advertisers move to more secure delivery methods, criminals are taking advantage of it to hide their tracks.
During the last year, online crooks have realized that buying ads and lacing them with malicious code is an easy and cheap way of infecting victims with malware and get some money out of it.
As a result, "malvertising" in 2015 has almost tripled from the year prior, even if security firms have focused more on this threat, tracking down and reporting several cases of malvertising to the advertisers and publishers.
Now, the fight against malvertising is about to get tougher for internet defenders as criminal hackers have found an unlikely ally: web encryption.
Websites all over the internet have increasingly adopted the the web encryption protocol commonly known as SSL or TLS, and also referred to as HTTPS, making connections between users and the sites more private and secure. Many sites, however, haven't been able to follow suit because many third-party ad providers don't support HTTPS.
But as more advertisers and ad networks start enabling HTTPS, criminals are beginning to make their activities harder to trace by serving their malicious ads over HTTPS, encrypting their tracks, according to security experts
"In the past weeks I've seen several sporadic malvertising campaigns on ad networks but was unable to reproduce and track them," Yonathan Klijnsma, a threat intelligence analyst at Fox-IT, told Motherboard in an email.
"I've seen several sporadic malvertising campaigns on ad networks but was unable to reproduce and track them."
Klijnsma explained that normally, when investigating a malvertising campaign, he tracks it down by going up the chain from an infection all the way back to the original ad.
What he specifically looks for, he added, is a unique ID called "creative ID," which identifies the person who pushed the ad—that's what the advertising company needs to disable the malicious ads and stop the campaign. This ID, as well as others that identify the specific campaign and publisher, are normally visible in the ad's URL, but if an ad served via HTTPS, they are effectively invisible.
"HTTPS makes it a lot harder to be able to get this 'creative ID' as it is inside an encrypted session between the victimized client and the publisher giving the advertisement content," Klijnsma said.
Jerome Segura, a security researcher for Malwarebytes who's been tracking malvertising threats for months, agreed with Klijnsma. Thanks to the adoption of HTTPS, "you can't track which campaign it was or which advertiser it was," he said in a phone interview.
This "is going to make life much more difficult for ad networks and security companies," he added. "You are at a new level, a new playing field where the bad guys have the advantage."
This "is going to make life much more difficult for ad networks and security companies."
That's the reason why a recent malvertising campaign that hit eBay and the Drudge Report, among others, was able to go unnoticed for three weeks. As Segura noted in his technical analysis of the campaign, the criminals avoided detection "by encrypting traffic" using HTTPS.
In these cases, Klijnsma explained, it's in theory possible to track down the criminals by performing a man-in-the-middle attack on encrypted sessions recreating the attack in a lab, but that's a more laborious and complicated procedure.
Perhaps, he said, one solution would be to allow only big advertising networks (think of AppNexus or Google's DoubleClick) to serve such ads, while others stick to "static content," such as images, videos or text. But this solution relies on publishers and big advertisers to police smaller, third party advertisers who are further down the chain and often buy and resell the ad impressions themselves.
At the end of the day, this is an issue of trust, according to Segura.
"Do you trust the third party to serve the content?" he said. "If you're not sure about that, then don't let the third party host the content. Host it yourself."
An earlier version of this article referred to an identifier in the ads as "create ID," but it is actually "creative ID."