Read the original article: Persistent malvertising attacker DCCBoost raged as the year faded
500k malicious ads served the week leading up to new years eve, over 25MM since.
As Twenty-twenty was coming to a close, the Security and Threat Intelligence team at Confiant was scrambling through fairly sophisticated JavaScript code to uncover the newest iteration of a well known threat actor. Behind several layers of fingerprinting, back and forth client-server chatting, and several client-side traps and obfuscation, hid variations of forceful redirects to unamusing gift card and lottery scam pages. By looking back into our threat intelligence and signals, we had come to a conclusion that our end-of-year “Grinch” was indeed no less that an old nemesis — DCCBoost had made a comeback.
In order to illustrate what I believe is a mastery of JavaScript exploitation and abuse, allow me to walk you through a sample chain all the way to the delivery of the scam.
Step 1
The initial payload is encoded inside the source attribute of the displayed ad banner. Upon passing some preliminary client-side fingerprinting validation such as navigator and mobile device targeting, a decryption routine kicks in to reveal the javascript that lives inside the image.
The decryption is a block cipher that gets reused from the initial dropping phase to the payload execution: each string is XOR’d with a key and base64-encoded to produce the cipher-text, and the symmetric operation happens at decryption to reveal the plaintext. There’s one interesting caveat, though:
All communications originating from their server to the victim’s client are keyed with the same hardcoded string, but data sent in the other direction, such as fingerprinting data that gets analyzed server-side, dynamically chooses a random encryption key.
How are they able to decrypt the messages on the server, you ask?
Below is the algorithm that “solves” the (in)famous computer science key exchange problem:
If you got lost in the cipher algorithm, this is like telling someone the keys to your house are hidden underneath the carpet at your entryway. But shh, no one shall know of this…
Here it is, directly from the code:
Step 2
Once the payload inside the image is decrypted, it gets evaluated to kick off the next stage. Here, common fingerprinting techniques are used, including device targeting, OS detection, canvas drawing, and most endearingly, attempts at detecting known ad-tech security vendors.
One of the observed payloads has a hardcoded set of previously-created hashes so as to stop execution if the client draws one of them at runtime, like a block list:
Here’s a rendered canvas drawing for fun with Chrome on a Macbook:
If any of the above conditions is ever met during execution, the payload runs a piece of code that returns early and redirects the iframe the script was running inside to about:blank.
This effectively disconnects the debugging session and terminates execution:
On the other hand, satisfied with the conditions on the client-side, the payload prepares an array of fingerprinting values that get sent to the server for evaluation. We’ve seen a few different ways to do that, sometimes even using less common protocols like WebSockets. In any case, the post data is quite extensive in some cases, and may look like this on an iPhone:
Finally, to build each request URL, the attacker goes an extra mile to hide the malicious domain. A meta tag hides the domain inside its content attribute like so:
The JavaScript code then queries for that tag, which is unique to the page by attribute charset=“utf=8”, and the content is decrypted, revealing the malicious domain. The URL is at once constructed with the domain, the encrypted random key, and a combination of query parameters that provide some context particular to the current client such as cookies, session, and the current stage of the payload execution.
Interestingly enough, the domain also shows up on the first step as a sourceMapping attribute. That may have been used in the past as a different strategy for smuggling the URL for the request builder, or a current active detection of DevTools server-side, where having the debugger open would cause the browser to try to fetch the URL and a listener on the server could detect that the current session is debugging the code (https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map).
By design, sourceMapping-fetching does not show up on the browser, but notice on the network flow how that plays out.
Here we load the ad without DevTools:
And now with DevTools open:
Mind the extra request at the end to
https://d3rjnps5uzsz5w[.]cloudfront[.]net/internal/sourcemaps/gwdpagedeck_min.js.map
Step 3
The last step only happens after the server-side component decides whether the client fits the targeting for the campaign. In case it does, the server shall respond back with yet another piece of javascript, which gets decrypted, injected and executed inside a try/catch statement:
This last piece of code eventually produces the redirection to the scam pages:
Impact & Scope
As we mentioned before, the security and intelligence team at Confiant has been tracking DCCBoost for quite some time now, and among the many samples we’ve analyzed, they seem to be putting extra effort into protecting their communication channel, either through encryption of payloads, dynamically building domains and URLs, or using WebSockets.
By and large, we estimate that over 25 million impressions with some variation of this payload have been registered over the internet spread across just about 40 distinct malicious domains hosting the server-side infrastructure.
As always, we continue to iterate on our signals to uncover and analyze new patterns and protect the ad world. Follow this and other malvertising tales at: https://twitter.com/confiantintel
Appendix: IOC Piñata
Here’s a list of observed bad domains from this attacker in the past month:
*.rwfkszdkjqakqf.net
*.oudrvrwxug.net
*.wfdbpvyzdo.net
*.ukidcniwciooqs.net
*.dddlneahzbm.net
*.lsqrzbdpvee.net
*.wmanulqwownu.net
*.eocjzpfndceso.net
*.bkucdcasfndpht.net
*.loomsaqppxcgjj.net
*.ozxswqkwlniitz.net
*.itynhabvjcifga.net
*.msstowgjsxrad.net
*.kgexomykflxwqjr.net
*.elirbtjwzhwoxtsy.net
*.uwrjrzazej.net
*.zxeeinzzmc.net
*.zmofdjowjslokk.net
*.pcrbkhtkytf.net
*.ixqsdpzhxkyjygs.net
*.hxulypgtnirl.net
*.bemdbfgxfslzmn.net
Persistent malvertising attacker DCCBoost raged as the year faded was originally published in Confiant on Medium, where people are continuing the conversation by highlighting and responding to this story.
Read the original article: Persistent malvertising attacker DCCBoost raged as the year faded