On December 4th, 2016, I had discovered that campaigns started using what would be called the “pre-landing” page or “pre-filter” page. If you’re looking at the file hosted on the server then you can see that it is named firstDetect.js. It was also uploaded to one of RIG’s backend servers on January 13th, 2017.
The basic idea of the script is to make sure that the current browser is Internet Explorer and that the browser is not a crawling bot. If everything checks out correctly then the host is redirected to the landing page via a POST request, where there is more script meant to aid in exploiting the system.
It should be noted that since its inception I haven’t noticed any modifications to this script. Furthermore, active campaigns like EITest and pseudo-Darkleech seem to not be using it anymore (somebody please correct me if I’m wrong about that).
However, during one of my most recent infections (click here to read more about that) I noticed that somebody had altered the code and added more verification scripts. Notably they added some checks for Fiddler and FFDec (JPEXS Free Flash Decompiler) as well as the VirtualBox and VMware hypervisors. Below is a snippet of the script that I’m referring to:
You can see that it is checking three paths for tools and VMs. The three paths include:
- C:Program Files
- C:Program Files (x86)
Also, there are some obvious signs that the code wasn’t completed as there is a commented out section talking about the type:”av” which is specifically referencing both ESET NOD32 Antivirus and BitDefender Agent, however, the code is missing. My guess is that this will be added shortly.
Similarly, all the applications cross-referenced have the same filetype:’pf’; however, the script is prepared to check for “if( appPath.filetype == ‘driver’)” – possibly another prospective expansion to the pre-landing page checks. A console.log feature is present for scenarios when the appPath objects are not classified as type object; however, the console log debug section is never printed even in the presence of undefined object types.
Furthermore, in the function “finishChecking()”; which is reached once the framesLoaded counter is equivalent to the number of appPath objects they’re checking for. There is an advanced for-loop that shows the only internal operation has been commented out; another allusion to an unfinished product.
Yet, it appears that regardless whether the user hits the “finishChecking()” function, as long as they’re not classified as a bot, the POST request will be made. Sections of code to return a 404 have been commented out, I’m unsure if these are upcoming features or code that hasn’t been removed.
For anyone interested in seeing the original page, as well as the commented out version, please continue down below to the following links on my Pastebin account:
Shout-out to my friend “irdivision” who commented out the script and co-authored this post.