Quite often I notice that unauthorized actors who compromise RDP access will execute a native web browsing application and navigate to a website such as whoer.net to enumerate browser header information, IP address, ISP, and a smattering of other host identification information. In reviewing these cases with forensic tools, I would also quite often see a hit for https://mc.yandex.ru/metrika/watch.js. Observing a .ru domain hit usually raises my suspicion level a bit, but I could not understand the context because there are not normally other .ru domains found during my investigation.
A little commonsense and research confirmed that “metrika” is Russian for “metric” and that examination of watch.js appears to reveal a web metric monitoring/tracking capability similar to Google’s Analytics reports offered to webmasters via its tracking code (https://support.google.com/analytics/answer/1032385?hl=en).
I dived a little deeper and confirmed this. (https://yandex.com/support/metrica/general/how-it-works.xml).
Hoping not to sound like a Wikipedia entry, for those of you that do not know, yandex.ru is a large (*the largest) Russian ISP and Tech company their country has. It’s like Google in America and the interwebz even report that Yandex has been rated “the most popular website in Russia” with significant presence/use in Ukraine, Kazakhstan, Belarus, Ukraine, and Turkey. I took a look under the hood at the whoer.net website and found my answer regarding the /watch.js file. So now I know that the two are connected. Navigation to the whoer.net website loads the /watch.js metrics/analytics tracker. I was curious of the forensic correlation and noted that in one of my cases, from the time that the Google Chrome Browser recorded actor navigation to https://whoer.net to the time it recorded a hit on https://mc.yandex.ru/metrika/watch.js was 47 seconds. To give context, I looked at my examination machine’s browser cache in loading the whoer.net website and the yandex.ru/metrika/watch.js JavaScript, and there was less than a 2 second spread. Sure, I can correlate from Terminal Services event logs that I have a logged in foreign IP during this timeframe, but its correlating the individual clues that makes us good at what we do and not just drones reading push-button program output.
Plus, 47 seconds?! Geez, the compromised system was brutally slow and its internet connection was terrible. That must have made the RDP connectivity nearly unbearable.
