Your Golden Ticket to Domain Admin – Microsoft’s Critical Kerberos Vulnerability – MS14-068


Microsoft issued a critical security bulletin on Tuesday November 18, 2014 (MS14-068) which stated there was a privately reported vulnerability found within the Kerberos Key Distribution Center (KDC) that could allow privilege escalation. The KDC authenticates clients and users, and issues session tickets and temporary session keys to users and computers within an Active Directory environment. The vulnerability exists in implementations of the KDC in Microsoft Windows and exists due to the KDC failing to properly validate signatures, which can result in forged parameters within a Kerberos ticket.

The KDC is a network service that runs on each Domain Controller as part of Active Directory Domain Services (AD DS) and by default listens on TCP and UDP port 88. Attackers that have access to a compromised domain user account as well as access to AD DS within an Active Directory environment could leverage the KDC vulnerability remotely. It would then be possible to elevate the privileges of the compromised user account to the role of Domain Administrator by sending the KDC a forged Kerberos ticket that identifies the user as a Domain Administrator. Once an attacker gains Domain Administrator privileges within an Active Directory environment they will be able to compromise any domain-managed system in the environment.


Unlike local privilege escalation vulnerabilities, an attacker that has a valid unprivileged user account within the domain can leverage this vulnerability remotely. Microsoft additionally stated within the security bulletin they are aware of limited targeted attacks that have attempted to exploit this vulnerability. Thus, it is reasonable to assume there is code in the wild that Microsoft has seen attempting to exploit this vulnerability. GuidePoint has not yet discovered enough information to exploit the vulnerability.

Affected Operating Systems

  • Windows Server 2003 and higher
  • Windows Server 2008 and higher
  • Windows Server 2012 and higher

For a complete list of affected hosts please refer to the MS14-068 Security Bulletin. In addition, Microsoft has released patches for Windows Vista, Windows 7, and Windows 8 and 8.1 as a defense-in-depth hardening of these operating systems. However, the Windows Vista, Windows 7, and Windows 8 and 8.1 operating systems are not directly vulnerable to this vulnerability.


Pre-Update Detection

To identify if an Active Directory environment has been targeted by any known exploits before updates have been applied to the affected systems, review Windows Security Event Log for Event ID 4624. This event is logged when successful logins occur within a domain. If the ‘Security ID’ and ‘Account Name’ fields of the log do not match, even though they should, it could indicate targeted attacks leveraging this vulnerability are underway.

Joe Bialek from the Microsoft Security Research and Defense blog illustrates pre-update detection very well within his detailed write-up of the MS14-068 vulnerability titled “Additional Information About CVE-2014-6324”. For additional information and illustration of pre-update detection it is highly recommended to read this blog post.

Post-Update Detection

To identify if an Active Directory environment is being actively targeted after applying the update to Windows Server 2008R2 and above, Event ID 4769 in the Kerberos Service Ticket Operation event log can be used for detection purposes.

Joe Bialek’s also illustrates post-update detection very well within his detailed write-up of the MS14-068 vulnerability titled “Additional Information About CVE-2014-6324”. Bialek explains event 4769 is a high volume event and it is advisable to only log failures of this event for detection purposes. For additional information and illustration of pre-update detection it is highly recommended to read this blog post.


Microsoft has released an out-of-band patch to remediate the MS14-068 vulnerability. Users should test and deploy the patch to affected systems domain wide. Please refer to the MS14-068 Security Bulletin for more information.


A Shock 19 Years in the Making – Microsoft’s Critical WinShock Vulnerability – MS14-066


The vulnerability defined in MS14-066 (CVE-2014-6321), or “Winshock” as the media has dubbed it, has been categorized as a critical risk due to the potential impact that includes denial-of-service, information disclosure, and unauthenticated remote code execution. Microsoft describes Winshock in KB2992611 as the “improper processing of specially crafted packets by the Secure Channel (SChannel) security package.” This package is closely linked to critical system services, and this condition creates the possibility for a remote, unauthenticated attacker to obtain SYSTEM-level access. That is, undoubtedly, the worst-case scenario which could plausibly become the precursor to worms and other widespread damage.


At its heart, the SChannel package is responsible for securing network communications with the SSL and TLS protocols. Numerous Microsoft service implementations including (but not limited to) IIS, Active Directory, Outlook Web Access, the Remote Desktop Protocol, and Internet Explorer utilize the SChannel package. However, due to the immediate lack of detailed technical information, it is currently unclear which of these services may genuinely be affected by this vulnerability.

For a detailed explanation on how to exploit the vulnerability, refer to the in-depth technical blog post by Beyond Trust that analyzes the patch and demonstrates how specially crafted SSL communications can be leveraged to target the vulnerable code and crash the operating system. The demonstration proves that not only is remote code execution theoretically possible, but that a simple denial of service condition is easily achieved by making a minor code change to the open source OpenSSL library.

It is important to note that the default IIS configuration does not accept client certificates. Additionally, other SSL/TLS-enabled services, such as Terminal Services, do not support client certificate configurations. However, new research demonstrates that (thanks to a second “bug” in Schannel) a malicious client certificate can still be utilized to trigger the vulnerability simply by configuring the attack technique to ignore the server configuration and submit the client certificate. While the service itself would ultimately ignore the client certificate in such a scenario, it will still be analyzed by the vulnerable SChannel code. In this case, any SSL/TLS service that utilizes the SChannel package, which includes all native Windows services, is conceivably vulnerable to exploitation.

At the moment, there are no publicly accessible exploits, nor have there been any reported cases of exploitation in the wild. However, Immunity Inc. has released a proof-of-concept exploit for subscribers that have access to their CANVAS Early Updates program. While the quality and reliability of this proof-of-concept are not disclosed, its existence confirms the feasibility of exploitation.

The technique demonstrated by Beyond Trust utilized client certificates to reach the vulnerable code. It is worth noting that Winshock appeared to address multiple code flaws, so client certificates should not be considered to be the only and definitive attack vector at this time. While a client certificate-based vulnerability would lack the prevalence of other recent SSL/TLS vulnerabilities, such as Heartbleed and POODLE, defending services affected by Winshock could arguably be a higher priority.


At this time there is no definitive way to determine if systems are vulnerable to Winshock. Anexia-it released a script that tests for the presence of four (4) ciphers that will exist on a system that has been patched against Winshock. This test, however, is not a guaranteed way to determine a system’s status in regards to Winshock. Microsoft includes a list of impacted Operating Systems (“OS”) in their MS14-066 advisory. If a system in your environment runs on an OS listed in the advisory, it would be safe to assume the system is vulnerable and proceed with mitigation steps to prevent system exploitation.


Patching for Winshock is a largely straightforward task, and public-facing servers should obviously be prioritized due to their increased exposure. However, there are significant concerns that should be considered before applying the Microsoft supplied patch. The most common concern is the potential for negatively impacted performance.

Various well-known vendors, such as Amazon, Blackberry and IBM, have reported noticeable application performance degradation, TLS session disconnections, and SQL server performance issues. Reports of performance problems extending to client applications, such as web browsers, have surfaced as well.

Microsoft has been largely silent on these issues, and the lack of guidance makes remediation all the more problematic. On the one hand, this is a critical system vulnerability that should ideally be patched post haste, but on the other, the patch may immediately harm the organization in an alternate manner.

Before installing the patch from Microsoft, GuidePoint highly recommends carefully examining your environment to determine if installing the patch is worth the potential risk of performance degradation, and to prepare a rollback strategy should problems arise after installation.

Intermediary security controls and alternate SSL/TLS configurations may provide an ideal, short-term solution for some organizations. GuidePoint recommends contacting your inline network and host-based security control vendors to determine whether signatures have been developed to block attacks prior to reaching the vulnerable service.

Additionally, Non-Windows SSL/TLS proxy servers and offloading appliances may prevent attacks from succeeding against the underlying Windows service, but these configurations should be thoroughly tested to ensure that malicious requests are properly dropped or modified and cannot be used to successfully exploit the service.