Category Archives: cyber threat mitigation

Windows Credential Guard & Mimikatz

Here at NVISO, we are proud to have contributed to the new SANS course “SEC599: Defeating Advanced Adversaries – Implementing Kill Chain Defenses”.

This six-day training focuses on implementing effective security controls to prevent, detect and respond to cyber attacks.

One of the defenses covered in SEC599 is Credential Guard. Obtaining and using credentials and hashes from memory (for example with Mimikatz) is still a decisive tool in the arsenal of attackers, one that is not easy to defend against.
With Windows 10 and Windows Server 2016, Microsoft introduced a feature to mitigate attacks to obtain credentials and hashes: Credential Guard. With Credential Guard, secrets are stored in a hardened and isolated section of your computer, inaccessible from the normal operating system.

Credential Guard relies on a new technology introduced with Windows 10 and Windows Server 2016: Virtual Secure Mode (VSM). VSM is based on the virtualization features of modern CPUs to provide a separate memory space where secrets can be stored. This separate memory space is protected (via hardware) from read and write attempts from processes in the normal operating system’s memory space.

When Credential Guard is enabled, the Local Security Authority Subsystem Service (LSASS) consists of 2 processes: the normal LSA process and the isolated LSA process (which runs in VSM).

Credential Guard

SANS SEC599 day 4: Credential Guard

Tools that recover secrets from LSA, like Mimikatz, are not able to access the isolated LSA process. They cannot extract passwords or inject hashes for pass-the-hash attacks, for example. Hence, Credential Guard is an effective tool to protect credentials stored on Windows machines.

Despite Credential Guard, users with administrative access can still find ways to steal credentials entered on Windows machines. This can be done, for example, with Mimikatz own Security Support Provider. SSPs are packages that participate in the authentication of users: for example, installed SSPs will be called when a user logs on, and will receive the credentials of said user. Windows comes with several SSPs , and custom SSPs can be installed (of course, this requires administrative permissions).

Mimikatz memssp command (available since September 2014) installs a custom SSP in memory (so no DLL is written to disk), that will log all credentials it receives in a text file.

To achieve this, Mimikatz needs to be executed with administrative rights on the target machine and the debug privilege needs to be enabled to allow the LSA processes to be opened and patched:


Next, Mimikatz’s SSP is injected with the misc::memssp command:


Now the SSP is installed, Mimikatz can be closed. This SSP will remain in memory as long as Windows is not rebooted.

After a user has performed a log on, Mimikatz’s SSP log C:\Windows\System32\mimilsa.og file can be examined to retrieve the credentials processed by Mimikatz’s SSP:



Mimikatz can not extract credentials protected by Credential Guard, but it can intercept credentials entered in a Windows machine at log on time, for example. Although Credential Guard will protect credentials in isolated memory, credentials still need to be provided to a Windows machine (like for an interactive logon).

When these credentials are typed, they can still be intercepted and stolen, e.g. with a key logger or with with a custom SSP, as illustrated here. This is however only one of the steps in the attack chain, as this requires administrative rights, it is crucial to restrict and monitor administrative access to your Windows machines.

Mitigation strategies against cyber threats

So it’s been a good 2 months since we have been in business! We thought we’d to take some time to reflect on these two months, in which we’ve seen quite some interesting security news including the well-known Mandiant report on APT1 and the widespread Java chaos.

Last week, ENISA published a “Flash Note” on Cyber Attacks, urging organizations to take precautions to prevent cyber attacks. In order to protect against cyber threats, they provide the following recommendations:

  • Protect targets to avoid weaknesses being exploited by adversaries: prevention should be the primary defence against attacks.
  • Consider the use of more secure communication channels than e-mail in order to protect users from spoofing and phishing attacks.
  • Proactively reduce your attack surface by reducing the complexity of software installed on user devices and reducing the permissions of users to access other devices, services and applications by applying the principle of least privilege.
While we believe these are good recommendations, we are also convinced that it is often not easy for organizations to practically implement this type of recommendations. 

An interesting, more practical perspective on defending against cyber threats is provided by Australia’s DSD (Defence Signals Directorate). In the same spirit of the “SANS Top 20 Critical Controls“, the DSD has summarized a top 35 of mitigation strategies to protect against cyber threats – a ranking based on DSD’s analysis of reported security incidents and vulnerabilities discovered on Australia’s government networks.

That top 35 is of course just another large list of security controls that should be implemented. Interestingly enough however, the DSD noticed that 85% of all cyber threats can be mitigated by only implementing the top 4 of these 35 strategies. This top 4 boils down to the following controls:

Let’s face it: with malware developing at the pace it currently does, it is unrealistic to expect that antivirus solutions will offer in-depth protection against every single malware infection. They are a good and necessary first step, detecting older and known malware, but the most effective method is not trying to detect malware: it is to allow only known, valid programs to run.

While application whitelisting clearly is the “way to go” with regards to security, it’s often not an easy choice for various reasons (“Damn you IT, this is not workable!”, “We are a company with an open culture, we don’t lock down our desktops”, “We trust our employees”,…). If you ever manage to convince your organization to consider application whitelisting, another daunting challenge awaits the IT administrator: creating and managing the application white list.

Now, establishing what ‘valid’ applications are for your environment is no easy task. Next to the usual client-side applications such as PDF readers and other office software, the list of approved software will also include applications specific to your environment. So how do you about creating / managing this type of whitelist? Here’s a couple of ideas:

  • To create your initial white list, a good idea would be to use a normal employee workstation and list all of the installed applications. In a reasonably static environment, this could be a good approach, seeing as normal employees wouldn’t be able to install new applications themselves anyhow.
  • A less “strict” approach would be the use of “software signing”. You could protect your environment by only allowing software signed by trusted developers / vendors to be installed.

If you cannot implement application whitelisting in a “blocking” mode, consider configuring it to only monitor (not block) applications that are not on the white list. This will provide you with additional insights on the software running in your environment, without further restricting your employee workstations.

When it comes down to tooling, there’s several commercial solutions available. For typical large Windows environments, a good solution is AppLocker which further builds on the older “Software Restriction Policies”.

This is where it all starts. We are still seeing too many organizations that lag behind when it comes to the roll-out of security patches for operating systems and server software. 

During the majority of our security assessments and penetration tests, we are frightened by the number of hosts that are missing 6-months old critical security patches. Unfortunately, any one of these critical risks is usually enough to compromise an entire Windows domain.

In order to keep abreast of new security vulnerabilities, organizations should set up an effective patch management process. I’m sure most of you have this type of process, so let’s take a closer look and see whether your process includes:

  • A security patch assessment that verifies to what extent security patches are applicable to the organization and what the actual impact is;
  • A release cycle for security patches that includes proper testing and a controlled release;
  • An emergency process for urgent and critical patches (based on the criticality of the patch, you should consider what the biggest risk is: following the process and increasing your exposure window or immediately applying the patch and risking availability issues?);
  • An overview of all systems and their configuration to ensure all concerned systems are patched;
  • A process for temporary workarounds;
  • A system that provides metrics and monitors the effectiveness of the process itself.
Server-side vulnerabilities usually receive the most attention from organizations, even though patching client applications deserves just as much focus. Using security’s weakest link (humans), attackers often use a combination of trickery (e.g. spear phishing) to exploit vulnerabilities in client applications.

Just consider the following vulnerabilities for JRE (the Java Runtime Environment):

Java Runtime Environment (JRE) vulnerability overview

These vulnerabilities often remain “hidden”, as your typical network vulnerability scanners (e.g. Qualys, NeXpose, Nessus,…) will not pick them up by default.

There’s a couple of ways of identifying what software is running on your client machines:

Network scanners can usually be configured to actually authenticate to hosts in your environment and detect vulnerabilities in the installed client software. Although this type of configuration works well and provides you with the required information, it is something that should be implemented and monitored very carefully. After all, you are providing an automated vulnerability scanner with (administrative) credentials to your client machines. I’m sure most of you had some incidents in the past where a vulnerability scanner did some things you didn’t expect (e.g. use an “unsafe check” that takes down a vulnerable server). Now imagine the havoc a scanner could cause when he has administrative privileges to 90% of your network.

Install “application monitoring” software on your client machines. An alternative to the above approach is to install a small monitoring tool on your client machines that sends information on installed software to a central server. You can then centrally track the different software versions in your network. A possible pitfall here could be privacy issues that would prevent you from installing this type of “monitoring software” on your employee machines, so it’s something to first check with your legal department.

Once a system has been compromised (in any way possible), an attacker will attempt to further escalate his privileges both on the system and inside the victim network. To minimize and to track administrative privileges will help you contain malware infections and compromises (which will eventually occur in any environment).

As a good example of this, many IT organizations have an abundance of administrative privileges attributed to IT staff (e.g. the majority of IT staff has domain administrator privileges). It is understandable that “the business needs to keep running”, but there’s a couple of ways to improve the situation without “crippling” system administrators:

  • Provide system administrators with two accounts: one for normal daily usage and one that can be used for administrative tasks.
  • Review administrative accounts and apply the least privilege principle, i.e. system administrators often require elevated privileges, but not “Domain Administrator”. 
  • Review application accounts and apply the least privilege principle, i.e. do not let your applications run with SYSTEM privileges.
  • Implement and enforce a proper IAM process for administrative accounts that will monitor the spread and usage of administrative accounts.

Over the years, a number of organizations invested time in creating “security control lists” to assist organization’s in minimizing their exposure to cyber threats. While most of these are good, we believe Australia’s DSD does a very good job in defining 4 concrete and clear mitigation strategies that can be applied to most organizations.

It’s clear that all of these controls deserve a dedicated blog post that provides additional insights in how they could be implemented. We do hope that this post has given you some food for thought and we’ll make sure to regularly provide you with more insights. 

If you’re interested in more NVISO updates and info on how we can help you, please visit

Mandiant APT1 report