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.
