Cloud Security Engineer

When Ad-Tech Traffic Looks Like DNS Exfiltration

During my SOC co-op, A lot of our endpoints was making DNS requests at an unusually high rate triggering the DNS Exfiltration Analytics Rule which we created. It turned out to be advertising infrastructure, and the follow up ended up teaching me more than the alert itself did.

What is DNS Exfiltration?

DNS exfiltration is when an attacker sneaks data out of a network through DNS queries. Almost every environment allows DNS outbound, so if you encode stolen data into the subdomain labels of queries against a domain you control, you get a quiet channel that most egress controls never look at. The usual way is host making a flood of requests with long url. That is what our detection fired on.

Detection logic

The rule watches for a high rate of DNS requests from a single host, combined with URLs that carry encoded data.

  1. Start with the web traffic log
  2. Find URLs containing an encoded IP
  3. Extract the base64 candidates
  4. Expand multiple matches and summarize occurrences
  5. Fix the base64 padding
  6. Decode base64 into a byte array
  7. Extract the hex values, clean and validate them
  8. Convert to a string and pull out the actual IP

The decoded values were our own IP addresses. The organization's NAT outbound IP, plus a few employee Windows endpoints, encoded into web requests. If you stop reading there, it looks exactly like exfiltration. The question is who is on the receiving end.

AD-tech

The entities attached to the incident were pl.primis.tech, match.deepintent.com, and prebid-server.rubiconproject.com. All of them are known ad-tech companies. tlx.3lift.com showed up constantly too, and that one belongs to TripleLift, a legitimate advertisement platform. The ids.* domains in the same logs pointed to tracking and device fingerprinting services.

So the conclusion was that these domains are known ad-tech, and the data encoding format is consistent with tracking and RTB payloads rather than attacker infrastructure.

RTB payloads?

RTB is real time bidding. When you load a page with ads, packages of data about you get sent out so advertisers can bid on showing you on information like device and browser info, geolocation, IDs, what you are interested in, what pages you visited. All of that gets encoded into the request, which is why one of our machine's IP addresses showed up base64 encoded inside a URL.

Frequently seen URL

  • tlx.3lift.com/header/notify, TripleLift's header bidding endpoint (SSP advertisement)
  • tlx.3lift.com/header/s2s, the server to server connection for the same platform
  • pl.primis.tech, match.deepintent.com, prebid-server.rubiconproject.com, all known ad-tech
  • np.liadm.com, LiveIntent advertisement
  • an ids.* identity sync domain that I suspect is a user tracker, since it kept appearing in other logs too

Investigation flow

First, expand the finding. One encoded IP became several once we expanded the matches, and we correlated those with device telemetry.

Then correlate identities. We mapped Sentinel's IP findings to Azure Entra and Active Directory entities to figure out which users and machines were actually involved. The IPs resolved to the corporate NAT and regular employee workstations, and we confirmed the endpoints themselves had made the outbound calls.

Last, verify the destination. We ran the URLs through website scanners to check they were not phishing or malicious, and confirmed they were advertisement platforms that either collect user data or bid on ads.

Two questions I wrote down afterwards and still don't have a great answer to: how do you check that a website is authentic rather than just "not flagged yet"? And what other verification methods should be part of this flow?

The fix was enabling browser tracking protection on the endpoints. My own thought went a step further: install an ad blocker that filters ad URLs, and this whole class of noisy traffic never leaves the machine in the first place.

Why can't we just ignore that URL?

Because adware doesn't stop at serving ads. The same kind of software sends browser cookies and saved autocomplete passwords back to its own servers, and that is exactly how credentials end up leaked. An ad-looking URL in the logs is a hint that the machines behind it might be running something that harvests credentials. Our external attack surface monitoring picked the story up from there.

External Attack Surface Management

This program watches the organization from the outside, watching vulnerabilities across all systems, assets that land on public or private blacklists, potentially insecure ports, SSL certificate problems, DNS health, SSH issues, and website header issues. It also covers brand protection like lookalike domains, phishing and evil twin websites, reverse logo search, web referral and web beacon monitoring, impersonated social media accounts and fake employee profiles.

EASM stealer logs

This is one of the function of EASM which is the data leak and dark web protection consisting of exposed credentials, stealer logs, mentions of the company across dark web forums, and leaked keys, tokens, and config files. We found a lot of password list URLs tied to the organization's subdomains.

What does it steal

  • saved usernames and passwords, which means direct account takeover
  • session cookies, which bypass passwords and MFA entirely
  • autofill data, so personal and company information
  • file paths, which show what apps and files exist on the machine
  • hostname, OS, and IP, which help identify the infected endpoint
  • VPN, FTP, and crypto wallet apps, which open up deeper access paths

Well you can think this is not serious. I was too. However this informations were found in the dark web.

Dealing with accounts

  • Personal accounts like Gmail, Yahoo: ignore
  • A vendor URL on the company domain or a corporate email: investigate and enforce a password change
    • If the email itself is leaked, change the email too

Now where did all these credentials come from?

Mostly the same place as the ad traffic. Spyware and adware that sends browser cookies and autocomplete passwords to its own servers through DNS or embedding into the body.

How to respond to an incident?

  1. Validate the email and identity. Is the account still active? Does the exposed email belong to an employee?
  2. Correlate the IP. Compare the stealer log IP against corporate IP ranges, VPN logs, and known employee geolocations
  3. Check the hostname against the asset inventory and EDR sources
  4. Correlate activity. Review VPN, Okta, MS365, and access logs for any sign the credentials were actually used
  5. Classify the risk and act on it. Force the password reset, rotate whatever was exposed