At CND our SOC analysts are inquisitive by nature; digging a little bit deeper and the further exploration of a lead in data is what we like to do. It's a bit like a prospector looking for that tiny fleck of gold that reveals a giant nugget; the detail is what matters and exploring it often leads you to threats you didn't even realise were there.
Whilst analysing machine data from a public facing and non-critical web asset that our SOC monitors, we identified some interesting user-agent data. There are several such unusual items we could write an article on but this particular one caught our interest as being novel. A user-agent for those wanting a recap is according to one definition:
The "User-Agent" header field contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use. A user agent SHOULD send a User-Agent field in each request unless specifically configured not to do so.
(rfc-7231) Source: IETF, 2014.
Indeed, all browsing requests should include a user-agent field and those that intentionally mask or obfuscate or alter it can prove interesting in themselves to analyse. There are changes proposed by various browser vendors, see the further reading section which may change UA in the future. Our unusual user-agent starts normally with 'Mozilla 5' and according to one sample of our data, a variation of this appears in 10 out of 10 top agents typically browsing. What makes this item noteworthy is that following the expected string appears SQL text that is attempting to select data from a database:
Mozilla/5.0/**/(Windows/**/NT/**/6.3;/**/Win64;/**/x64)/**/AppleWebKit/537.36/**/(KHTML,/**/like/**/Gecko)/**/Chrome/37.0.2049.0/**/Safari/537.36,(SXXXXT/**/yyyy/**/XXXX/**/(SXXXXT/**/ROW(yyyy,yyyy)>(SXXXXT/**/COUNT(*),CONCAT(0x71626b6a71,(SXXXXT/**/(ELT(yyyy=yyyy,1))),0x716b7a7a71,FLOOR(RAND(0)*2))x/**/XXXX/**/(SXXXXT/**/yyyy/**/UNION/**/SXXXXT/**/yyyy/**/UNION/**/SXXXXT/**/yyyy/**/UNION/**/SXXXXT/**/yyyy)a/**/GROUP/**/BY/**/x))s)
(exact data has been redacted to reduce abuse)
Our analysts cross referenced reputable sources and one such source provided matches on MySQL-JSON Cross-Site scripting vulnerabilities, which purportedly have been exploited on CentOS 7 (*nix) platforms.
The exploit if successfully executed apparently 'breaks the web application' and thus your organisations online calendar (if vulnerable and using this specific package) becomes unavailable. This appears to be low-level defacement of vulnerable websites and not a particularly notable threat with limited potential for in-depth attack, albeit somewhat novel in approach.
There were 731 attempts by just one IP address to run the exploit on this occasion and using this data to cross-reference domain ownership where it implies* a geo-location of St Petersburg, Russia. The range has a relatively poor reputation and several IP's in the subnet are marked as threat actor sources, so essentially it could be deduced that this hosting provider is a safe harbour for malicious threats or that several machines hosted there have been compromised (I won't speculate further).
There was one more piece of data gathered at this point and that was the attributed network owner, an individual named: Chelyshev Sergej Aleksandrovich. A basic search engine lookup of this individual without a full OSINT and enumerated effort revealed an interesting immediate finding:
Sergei Aleksandrovich is an Officer in Russian military intelligence wanted by the U.S. FBI for cyber crimes in relation to 'False Registration of a Domain Name' related to the alleged election interference in 2016; indeed the FBI poster makes for an interesting read. Unfortunately, there is no evidence to suggest this is the same Sergei who owns this network and I suggest that this may be a common combination of first and last names but it certainly peaked our attention temporarily. [understatement]
So the question is have you checked your machine data for this style of rogue user-agent attack? Have a search for this Hex string to start with and see what you find:
0x716b7a7a71
We'll publish another user-agent attack in the next couple of weeks and explore some of the common themes we encounter that we can share. If you're concerned about the issues raised in this article or need advice or guidance about effective monitoring of your infrastructure, get in touch we can help.
(*Geolocation data should be treated as implied only and not necessarily factual without verification.)
Further reading:
NCSC:
ZD Net:
Comments