End-To-End Trusted Execution Path - Follow Up I

I talked about the importance of the end-to-end trusted execution path in an earlier post.  In that I alluded to the possibility of follow up posts on this topic, because of the potential this topic holds.  I recently stumbled on a blog post that reminded me of its relevance.

The blog post I am referring to pertains to mitigations against Mimikatz style attacks.  Among other things, it talks about how Mimikatz found a way to circumvent Credential Guard.  To quote the blog directly, " While prior to this Mimikatz could harvest hashes directly from memory, what this bypass does is harvest credentials as they are entered - before they get to that protected memory area."  I would suggest reading the referred blog for further details.

Another blog post on Credential Guard/MimiKatz as well talks about how MimiKatz circumvents Credential Guard.  To quote that article, "When these credentials are typed, they can still be intercepted and stolen, e.g. with a key logger or with a custom SSP, as illustrated here."  And here is another blog post dwelling into the same issue.

Based on the above mentioned blog posts, it is clear that irrespective of the level of protection afforded by newer technologies, Mimikatz like tools find a way to circumvent those protections.  In the case in question, SSP interface enabled the circumvention.  The attack vectors opened up by such APIs was provided by the same vendor that also provided the added protection!  Such scenarios can perhaps be avoided by allowing a more stringent use of those APIs, at least in production environments.  However, it still leaves the environment vulnerable by way of HID devices through which sensitive information is often times fed and the vulnerabilities they introduce.  This situation all the more accentuates the need for an end-to-end trusted execution path, as described in the initial post.