Tracking down HTTP push notifications

We were recently contacted by one of our customers to investigate some popups that were appearing on one of their users' workstations.

The user, who was thankfully a member of staff, received a popup notification asking "Do you like big girls?" and featuring some fairly risqué pictures. The customer was obviously concerned that this had not been picked up by their filtering and so asked us to investigate why this had happened.

The notification was a Web Push Notification. You may have seen websites pop up a "example.com wants to send you notifications?" box - if you click Allow, the web site can send you notifications even when you don't have that web site open. This is especially useful for webmail, social media, etc. which can notify you when new messages arrive, but it can also be abused.

The way push notifications are delivered is quite different to a normal web page. When your web browser requests a normal web page, it connects directly to the web server, makes the request and the web server responds with some data. For push notifications, there is no direct connection between the web browser and the web server, and the notification is instead sent via a relay.

In this case, the user was using Microsoft Edge, and the notifications are therefore relayed through the Microsoft Windows Notification Service (WNS). Which brings us to a few problems:

Although the school's Opendium UTM online safety system supports full HTTPS decryption, Windows does not allow the connections to Microsoft's WNS servers to be decrypted, so there is no way for the system to examine the notifications.
Even if we could decrypt the WNS connection itself, the individual notifications are also end-to-end encrypted, so neither the school's UTM nor Microsoft themselves can examine the contents of the notifications.
WNS is required by core parts of Microsoft Windows, and whilst we could block it entirely, this would break many core operating system functions.

However, there are a few things we do know. The notification popup itself said it came from myedytaclub.com. As mentioned, there is no direct connection between the browser and the server, so the UTM's logs didn't show any requests to myedytaclub.com at the time that the popup appeared. However, the notification data being relayed are expected to be quite small and the popup included 2 quite risqué images - the images themselves would not be embedded in those data. We asked the school's Opendium UTM to produce a logs report for the relevant time period, and since the logs report includes a thumbnail of each image that was requested, it was easy to spot those images in the report. This showed that the images had both been downloaded from cdn.adx1.com.

adx1.com is an advertising network and had the school set their Opendium UTM to block advertisements, these images would have been blocked. Ideally, since these images were pornographic, we would have wanted the system to also categorise them as Pornography and therefore block them anyway, but unfortunately there was not enough context available for dynamic categorisation.

Having determined where the popup had come from and why it wasn't blocked, we wanted to know how the user had become subscribed to these popups in the first place. By examining the UTM's historical logs, we could see that the user had visited the offending website (myedytaclub.com) around a week earlier, and had been directed there from kidsworksheetfun.com.

The kidsworksheetfun.com website looks like a completely legitimate website, hosting educational worksheets for children. However, it contains advertising, much of which is pornographic, and intermittently redirects visitors to myedytaclub.com and jennyvisits.com, which in turn frequently redirects visitors to www.be2.com (a dating site). Its also plagued with popups encouraging visitors to download malware. All in all, pretty inappropriate stuff. The source of all of the inappropriate content seems to be a script that is being loaded from www.effectivecreativeformat.com. The contents of the script is heavily obfuscated and looks like malware, although its also possible that it has been obfuscated in an attempt to frustrate adblockers.

A Web Searches report shows that the member of staff reached kidsworksheetfun.com through a completely innocent search of Bing Images.

We strongly suspect that kidsworksheetfun.com has been hacked, but it is also possible that they have made an extremely bad choice of which advertising network to use to support their website. The kidsworksheetfun.com lists a number of email addresses to contact, and we have attempted to report these problems to them. Unfortunately, none of the email addresses work.

All of the offending sites, including kidsworksheetfun.com, have now been added to our Malware category. Whilst it is unfortunate that this means we are blocking a legitimate looking website, it is clearly the right thing to do until the problems with it are resolved. Unfortunately, since none of their email addresses are working, we do not expect the problems to be resolved soon so it will likely remain blocked for the foreseeable future.

So, we can draw up a timeline of what happened:

2023-01-06 15:10: The user visited Bing Images and made a number of completely innocent searches.
2023-01-06 15:10: Amongst the images found by Bing Images were images from the kidsworksheetfun.com website.
2023-01-06 15:11: The user clicked on one of those images and was therefore taken to the kidsworksheetfun.com website.
2023-01-06 15:11: The user was then redirected to myedytaclub.com.
2023-01-06 15:11: We believe that they would have received a "myedytaclub.com wants to send you notifications?" popup.
2023-01-06 15:11: We believe the user accepted the notifications - possibly because they thought it was from an education site (kidsworksheetfun.com).
2023-01-06 15:11: The user went back to browsing images in their Bing Images search.
2023-01-13 08:14: Around a week later, myedytaclub.com started sending pornographic notifications to the user.
2023-01-13 08:14: The pornographic images embedded in the notification were downloaded from cdn.adx1.com.
2023-01-13 11:00: The school asked us to investigate.
2023-01-13 13:48: We added a number of domains to our Malware category as a result of our investigations.
2023-01-13 14:48: We added additional domains to our Malware category as a result of our investigations.
2023-01-13 15:15: A report was finalised and sent to the school and we advised them to update the user's browser settings to unsubscribe them from the notifications.
2023-01-13 16:44: Response from the school thanking us and confirming that they had unsubscribed the user from the notifications.

Although it is unfortunate that the UTM was not able to block the notification, this has been a good outcome: the customer is very happy with the explanation and detail we have been able to provide, and the updates to the Malware category should help to prevent anyone else from becoming subscribed to these notifications.