Suspicious Registry Keys and Requested files: A Threat Grid Case Study

Threat Grid’s detections and indicators are created by the Research and Efficacy Team, or RET. The RET’s primary objective is to improve the detection rate of Threat Grid. As such we have to keep up with new malware campaigns and exploitation techniques. This often requires manual analysis of samples, which is an incredibly time-consuming process. As part of this duty, we must make use of automation tools to speed up our analysis. Threat Grid is chief among those tools, and we will be discussing an example where Threat Grid highlighted everything necessary to make a determination on a file.

The sample in question at first glance appears to have barely executed.  Threat Grid did convict the file, but not in the way or for the reasons we would expect. I dug into the sample in more detail to find out why.  A sample that is convicted due to static analysis only but exhibiting little dynamic behavior is indicative of evasive malware and warrants further examination by our team. To start off I checked into each indicator to determine, at the highest level, what has gone on.

Checking the AV indicator revealed that there were a great many hits on this file, and as such the chance of a false positive is low. The next three indicators triggered on the same two executables, both of which were placed in the AppData folder.

While the naming on the two files is odd and seemingly composed of arbitrary characters, it is far from enough to make a decision on the sample yet. However, the next three indicators again pertained to the same two executables, which supported the hypothesis that these oddly named files are malicious.

After all the indicators regarding the sample and its two created files, the next indicator in the list above is “DNS Query Returned Non-Existent Domain”. This can happen for primarily one of two reasons – the sample is either looking for command and control services that have either not yet been set up or have been already taken down, or the mere existence of the domain is being used as a signal to trigger an action, typically an abort or a proceed. With the abort option, the domain functions in essence as a killswitch; with the proceed option it is the opposite and the malware will “lay low” so as to not attract attention until the malware author or owner wants to activate it. Either way, this activity warrants further investigation of the sample – neither of these reasons are typically indicators of benign intent.

The remaining indicators on the report provided little additional info as the two executables were already suspicious enough to investigate.

The network section of the report was also of little use in this case, since as we mentioned above, the domain did not resolve, and so no important communications were established.

The process section can be incredibly useful but can easily overwhelm a user with the sheer amount of data available under each process. As such I typically do a first pass looking only at the names and number of processes and return later if applicable. In this case nothing stood out. I apply the same principle to the artifact section, where again nothing stood out besides the names of the two executables.

Proceeding to the Registry Activity section of the report proved to be very interesting. The sample created a rarely-used registry key with an executable path as its data. It was via review of Threat Grid analyses that we discovered this unusual and typically maliciously-used run key, and because of this discovery the system now flags such usage as suspicious via a Behavior Indicator created for that purpose.  As it turns out, the data points to one of the oddly named executables we saw earlier. This type of run key coupled with the suspicious features of the executable is indicative of malicious behavior.

Proceeding to the File Activity section of the report is often unnecessary, especially now that we can definitively state that this is malware. For each row in this table there is an “action” listed – I find that the paths that are shown only with an action of “requested” are sometimes quite interesting as entries here are either files that were requested but that do not exist on the system, or are other system resources such as pipes. In this case what I found was rather astonishing. The submitted executable requests a cuckoo pipe. Cuckoo is a publicly available sandbox generally used for testing by developers. The Cuckoo pipe shows up only as a requested item because Threat Grid in no way uses Cuckoo, so there is no possibility of any Cuckoo related resource ever being found. This sandbox check, in conjunction with the non-existent domain, allows us to conclude that the sample is definitely employing sandbox evasions. Since the sample is most definitely bailing out before the full execution has completed a new indicator detecting the Registry Key Modification is being created.

Although Threat Grid did initially convict this file based on static analysis results, I wanted to find out why the dynamic analysis results did not match. Because of the level of detail provided in the analysis report, I was able to quickly determine why the sample did not execute completely – as well as what malicious actions it had performed up until it bailed out.

Threat Grid allows me to do my job far more efficiently and effectively than I would be able to without it. It can be used to quickly determine a file’s obvious level of threat and as shown here it can also be used to dig deeper into a file’s activity, sometimes with interesting and unexpected results. If you have a portal account, take a few minutes to look into the features described above in an analysis report of one of your files, or any of the public files – you might be surprised with what you find!