Does signed mean trusted? The Mimikatz dilemma

Back in August 2018, Red Canary Detection Engineer Ben Downing was working the queue when he received a suspicious event from one of our generic malicious reputation detectors: An executable named sklquery.exe was likely malicious based on a reputation score from one of our partner vendors. Ben needed to answer the following questions in a timely manner:

• Why might it be flagging as malicious?
• What might sklquery.exe be?
• How do we confirm that it is malicious?
• If we confirm that it’s malicious and ship a detection to the customer, what context should they have to respond appropriately and confidently?

The short answer to these questions stems from the fact that a majority of security vendors identified the executable as Mimikatz. sklquery.exe is a signed and expected component of the SkyKick Outlook Assistant Office 365 Migration utility. Yes, repackaged and legitimately signed Mimikatz. Ben rightly confirmed it as malicious in spite of its appearance as a legitimate software component. Ultimately, it should be up to the customer to adjudicate if such an offensive utility is expected and authorized in their environment. We would be irresponsible to not alert a customer to the presence of the utility and supply them with sufficient context to make an informed decision.

What follows will be the quick-thinking process Ben followed in arriving at this decision as well as some additional analysis the threat research team applied to better understand this suspect executable.

Notable observations

When triaging any event, one must make as many relevant observations as possible with the information available to first conclude whether or not the event surfaced is indeed malicious/suspicious or confirmed benign. Ben determined the following:

sklquery.exe was dropped to C:\Program Files\skykick inc\sklquery by msiexec.exe

Here’s what this activity looked like in the actual endpoint telemetry:

Without additional context, this implies that msiexec.exe likely ran with elevated privileges so that it could be dropped into a sub-directory of C:\Program Files, a directory that, by default, requires elevated permissions to perform file and directory writes. It also implies that the file would have sufficient privileges to execute privileged functionality, for example, like dumping credentials from lsass.exe.

The “skykick inc” installation directory offers a degree of credibility, but the name of a directory is insufficient to prove the legitimacy of an executable. It does, however, serve as a data point to consider in determining whether or not this executable is expected as a component of a potentially legitimate software installation.

sqlquery.exe was packaged within sklquery_x64.msi, which was executed from the user’s Desktop directory

Without additional context, this could imply that the MSI could have been manually downloaded and an installation manually initiated, which, in turn, could lend credence to a narrative that this installation was intentional. Intentional or not, however, such an observation would not have influenced a benign or malicious classification. It does serve as a relevant data point in contextualizing the event should it be published as a malicious detection to the customer.

sklquery.exe and sklquery_x64.msi were signed with the following certificate subject: CN="SkyKick, Inc.", O="SkyKick, Inc.", L=Seattle, S=Washington, C=US

Between the “skykick inc” directory and the “SkyKick, Inc.” signature, there is more evidence to point to a potentially legitimate entity distributing this executable. Indeed, SkyKick is a legitimate business based out of Seattle that appears to primarily offer cloud migration services.

It’s also worth noting that the certificate has since expired and is now invalid. Normally, certificates would remain valid after expiration if they were timestamp countersigned, but sklquery.exe was not timestamped. The reason for the invalid certificate is relevant because it appears to have been signed with a legitimate certificate rather than being generated from a cloned certificate or the executable being tampered. Cloning and tampering in this context would suggest the presence of an adversary and pretty clearly indicate that this activity was suspicious or malicious.

No time for hemming and hawing

As of this writing, 51 of 71 security vendors classify this executable as malicious, many of them applying a Mimikatz detection label. That this executable is very likely a version of Mimikatz is pretty damning evidence on its own. Of course, more detailed analysis would confirm as much, but when working the queue, analysts understandably do not have the luxury to reverse engineer executables. After all, every moment that passes is a moment that a customer is left in the dark about a potential active compromise. More detailed analysis can always follow later, and this case was no exception.

Without additional analysis necessary, Ben shipped the detection to the customer with the relevant context needed for them to adjudicate its legitimacy or not. As was expected, they understandably marked the detection as “not remediated (this is authorized, non-testing activity)”. For this customer, this was expected activity and not entirely unsurprising in the course of gathering credentials for cloud migration in an automated fashion.

So case closed, as far as that customer was concerned. But the following question lingered: Do we consistently ship detections for sklquery.exe moving forward?

To answer this question, it’s helpful to ask how an attacker might go about abusing a signed version of Mimikatz. If an attacker could generically abuse sklquery.exe without relying upon an existing installation of Outlook Assistant, that would increase our confidence in our malicious classification. It is important that we be consistent in our decisions so that we don’t treat one customer or one event differently, intentionally or not. If, however, we discovered through further investigation that there did not exist a generic means of attacker abuse, then we would reconsider our malicious classification. In order to further shape our confidence, more detailed analysis of sklquery.exe is needed.

Follow-on analysis

We spent a little bit of time analyzing sklquery.exe to better understand what it’s doing, to determine if an attacker might be able to abuse it, and to confirm with high confidence that it has an expected, legitimate use within the broader Outlook Assistant product.

Our static analysis confirmed that it was only a minimally modified version of Mimikatz that made the following modifications:

• It does not write any output to the console
• It selectively writes some output to a named pipe with the following name: CVIPCSKListener
• The output written over the named pipe consists of some debug information and credential material discovered in an encrypted form (using the RC2 block encryption algorithm) using the following string as the basis to derive an encryption key: 243598243. Specifically, the following “kprintf” calls in the original kuhl_m_sekurlsa_genericCredsOutput function were replaced with functions that write the encrypted credential material to the named pipe

To attempt to interact with sklquery.exe, we developed and ran the following PowerShell code:

We were curious why it wasn’t also outputting collected credential material despite configuring our VM to produce intentionally recoverable credentials but we didn’t want to spend a ton of time performing root cause analysis. We already had enough information to confirm that this was indeed a repackaged and slightly modified version of Mimikatz and that it could likely be abused by attackers who are willing to set up their own named pipe listener.

Next, we wanted to confirm that there was at least one reference to sklquery.exe made in other code components. We pulled and analyzed the outlookassistant.zip installer and found where it was executed in helpers.primary_output, a .NET DLL component of the Outlook Assistant installation within the SkyKick.MigrationAssistant.Helpers.ExtractorProcess.start_sklquery method. We stopped our analysis upon confirming the reference to sklquery.exe in another code component.

Conclusion

In the end, Ben had every reason to be confident in his decision to ship the detection to the customer. Upon analyzing the binary further, our confidence level only increased on the basis that this was a confirmed, repackaged version of Mimikatz, signed by a vendor, that exhibited the opportunity for easy abuse by attackers.