| | | | Trustworthy Computing | January 2015 |  | | Microsoft Security Newsletter | | | | | | | | | | Welcome to January 2015’s Security Newsletter! | This month’s newsletter theme, securing account credentials, is paramount to helping businesses and Internet users protect their accounts online. In a world where personal account information is a commodity to cybercriminals, we can no longer expect account names and passwords to be the sole security access points.
In our 17th volume of the Security Intelligence Report (SIRv17), which covers threat intelligence from January 2014 to June 2014 as well as longer term trend data, Microsoft tracked about 1,700 distinct website credential thefts—comprising a little more than 2.3 million credentials that were posted in public places on the Internet.
So, is multi-factor authentication the answer for better credential security? For many small organizations and consumers, a combination of Short Message Service (SMS) authentication or one-time code generators along with diverse, randomly generated passwords is a sufficient solution. For businesses and other large organizations; however, you might want to employ more robust and scalable solutions. For more details and guidance, please check out the "Securing account credentials" section of the SIRv17 at www.microsoft.com/SIR as well as the resources in this month’s newsletter.
 | | Best regards,
Tim Rains, Director
Cybersecurity & Cloud Strategy, Microsoft |
Have feedback on how we can improve this newsletter? Email us at secnlfb@microsoft.com and share your ideas. | | |  | | Top Stories |  |  | | | | Navigating Security in the Age of the Breach at the Evanta CIO Executive Summit
Explore some of the discussions that took place at the 2014 Evanta CIO Executive Summit and find out which components of security strategy were top of mind for summit panelists.
Proposed Cybersecurity Norms to Reduce Conflict in an Internet-dependent World
Today, all over the world, public utilities, banks, and governments use the Internet, cloud services, and mobile technology to enhance their productivity. Unfortunately, the benefits of greater connectivity have also brought about increased information security threats, some stemming from nation state activities in cyberspace. Check out Microsoft’s recommendations on six cybersecurity norms designed to reduce the possibility that Information Communication Technology (ICT) products and services are used, abused, or exploited by nation states as part of military operations.
New Version of BinScope Binary Analyzer
BinScope, available as a free download from the Microsoft Download Center, was designed to help detect potential vulnerabilities that can be introduced into Binary files. Learn about improvements, such as improved diagnostic messages and performance, and download the latest version.
| | | | | Security Guidance | | | | Security Tip of the Month: Improve Security with Identity Management – Password Hashing and Reports
Find out how users can use their work credentials to authenticate against Azure Active Directory and gain access to Software as a Service (SaaS) applications in any public cloud, but also to on-premises applications—and how you can use Azure Active Directory (Azure AD) security reports and alerts to get a clear view of who has access to what when it comes to public cloud SaaS applications.
Active Directory: From On-Premises to the Cloud
Azure Active Directory is AD reimagined for the cloud, designed to help you solve the new identity and access challenges that come with the shift to a cloud-centric, multi-tenant world. Explore the role of Identity Management as a Service (IdMaaS), single sign-on deployment options, multi-factor authentication, and more.
TechNet Virtual Lab: Azure Active Directory Fundamentals
Find out how you can manage your organization’s identities by using on-premises Active Directory Domain Services, Microsoft Azure AD Premium, device registration, multi-factor authentication, and SaaS app integration. It focuses on devices that are not domain joined, regardless of whether they are owned by the organization or a user.
TechNet Virtual Lab: On-Prem and Cloud App and Data Protection with Azure RMS
Learn how to protect files from unauthorized access by using Microsoft Azure Rights Management, the Microsoft Rights Management connector, the Rights Management sharing app, and Microsoft Office 2013 regardless of whether your devices are domain-joined or stand alone or the devices are owned by the organization or the user.
Configuring Additional LSA Protection
The Local Security Authority (LSA), which resides within the Local Security Authority Security Service (LSASS) process, validates users for local and remote sign-ins and enforces local security policies. Find how Windows 8.1 provides additional protection for the LSA to prevent code injection by non-protected processes, which provides added security for the credentials that the LSA stores and manages. For more information about the LSA and the LSASS, see the Windows Logon and Authentication Technical Overview.
Protected Users Security Group
The Protected Users group triggers new non-configurable protection on devices and host computers running Windows Server 2012 R2 and Windows 8.1, and enables additional protections for domain controllers and domains in Windows Server 2012 R2 domains. Find out how to use this group to greatly reduce the types of credentials available when users are signed in to computers on the network from a non-compromised computer.
How to Configure Protected Accounts
Windows Server 2012 R2 includes new features to help mitigate Pass-the-hash (PtH) attacks. Learn how to configure the Protected Users security group, authentication policies, and authentication policy silos.
| | | | | Community Update | | | | Credential Theft and How to Secure Credentials
By Dana Epp, Microsoft MVP – Enterprise Security
I’ll never forget the day. It was Valentine’s Day in 2006. Bill Gates was on stage at the annual RSA Conference conducting a keynote speech related to next generation trust and announced that Microsoft was laying the foundation for change, so that in the next three or four years, corporate systems would not need to rely on passwords. He explained the vision to simplify certificate management and drive identity management through an interesting piece of technology called InfoCards. It was a bold announcement and a pretty cool demo; could Microsoft really take on and solve the challenge of having to eliminate the need to use weak password authentication? Could password fatigue really be behind us by 2010?
Well, it’s 2015 and we all know the answer to that. While several key pieces of the identity metasystem for InfoCards remain in the guts of the Windows operating system and many bits laid the foundation of what became Microsoft’s federation strategy, we still use passwords. Everywhere. And what’s worse, we now have more of them. On our desktops. Our phones. Our tablets. Heck… I had to log on to my TV this morning to apply an update. With the Internet of Things (IoT), password authentication isn’t going away anytime soon.
Adversaries are happy about that. Password authentication, especially in Windows environments, opens up huge attack vectors that make it almost trivial to laterally move throughout the network. You may have heard about these techniques under the veil of "pass-the-hash" or "pass-the-ticket" attacks. In fact, last year at TechEd, Mark Russinovich and Nathan Ide did a great presentation to demonstrate how attackers spread across a Windows network using this technique. I encourage you to check it out.
So just what can we do about it? Well, there are several key pieces of technology built into Windows that you can use to help secure your credentials and make it much more difficult to have them stolen and reused. From what I am seeing in the field, very few people seem to be using these security features. So let's explore them and see if I can convince you why they are valuable assets in your IT security toolkit.
For this article, I am looking at this issue from the viewpoint of an IT administrator. Consider the type of access you typically have with those type of credentials. If an adversary is able to impersonate you in this context, chances are the game is over. So our goal should be to restrict how and where we use these credentials. Let's start by discussing how to reduce the credential footprint.
The crux of Administrator credentials
It shocks me how many people use the primary domain Administrator account to log on to pretty much everything in a Windows domain. This is a bad practice, and should be frowned upon. That account has far too many privileges, and poor use of the account exposes you to great risk. It becomes trivial for an attacker to elevate and take control of the domain when there is credential residue from any account that exists in the Domain Admins group… but when you use the primary administrator "500" account you take it to the next level. Why? Because after you have control of that account you can lock out pretty much everyone. It is difficult for a member of the Domain Admins group to seize control of the primary domain Administrator account; the same is not true the other way around. Let’s come back to that in a moment.
Let’s start by talking about the local Administrator account. This is where most attackers begin their adventure to steal credentials. I won’t get into the fact that most deployments these days include ways that a user can elevate to local Administrator privileges with a single click of a button. I hate this. I wish more companies would actually deploy Windows to make users and applications run as standard users and force them to use UAC in prompt mode, instead of consent. The key difference being you then need to enter in the local Administrator password to elevate. Then again, it's quite easy to get that password… or at the very least reset it.
If you are a fan of my Web TV show "Crack the Cred," you may have seen a demonstration I did in episode 104 where you can use the Microsoft Desktop Optimization Pack (MDOP) to generate a Diagnostics and Recovery Toolkit (DaRT) USB stick that includes a tool called Locksmith. This tool allows you to reset the local Administrator account in just a few clicks, which takes control over the computer in a supported way by using tools Microsoft provides to its partners. The fact is though that these days, most Windows desktops are built in a way that it may be even easier to gain access.
In many cases, deployment images end up using the same local Administrator account. In fact, on many occasions I have seen IT teams forget to clear out critical files like the sysprep.inf, sysprep.xml, and unattend.xml files, which hold either plain text or base64 encoded plain text administrative credentials. That’s right. There is a good chance you can retrieve the local admin creds in clear text in a file left from the IT team when they made the deployment image for your desktop. And if you use Group Policy Preferences, it is trivial to extract the encrypted password because the AES key used for it is actually published on MSDN! Have I scared you yet? Surprisingly, not everyone knows about this credential residue during automated deployments. But your adversaries do. In fact, there are hacking tools that scan and extract these in just a few seconds, making it easy for them to gain local Administrator privileges on all of your computers across the network that use that same credentials. This allows lateral movement in an effort to find more privileges on other more-trusted systems. This leads me to our first mitigation.
Prevent network logon for local accounts
Local accounts are stored in the Security Accounts Manager (SAM) database, which is part of the registry. If the SAM has the same username and password (like when using automated deployment) an attacker can use NTLM and move laterally from one device to another without any trouble. If these computers are on a domain, you really shouldn’t be granting this. So one mitigation technique is to simply not allow that.
In the Security Policy Editor (secpol.msc) under "Local Policies–>User Rights Assignment’ there is a policy called "Deny access to the computer from the network". Introduced in Windows 8.1 and Windows Server 2012 R2 is a new well known group called "NT AUTHORITY\Local account" or just LOCAL_ACCOUNT for short. If you add that to the policy, then local accounts on the computer cannot be used across the network. So even if someone knew the password, it could not be used to remotely connect to another computer. This immediately eliminates the primary method of moving laterally across the network in search of higher credentials.
Prevent access to in-memory credentials
When sessions are established in Windows, a reference-counted object is created to maintain the session. The problem is that stale sessions still have a handle to that credential in memory for the lifetime of the connection and could keep it indefinitely… at least until the computer is restarted. Think about it… how many times have you closed an RDP session to a server without actually logging off? When you do that, your credential stays in memory. And even if you do log off, stale sessions may become orphaned and the credentials could be left in memory regardless. If you allow lateral movements from other servers as shown in the last section, it means it would be possible for someone with Administrative privileges to steal your credentials. Tools like Mimikatz make this extremely easy to do.
There are several ways to reduce this risk. First off, by default, operating systems newer than Windows 8 have had the credential footprint significantly reduced, wiping the plain text value out of memory. So you immediately benefit if you have upgraded. However, there is more you can do to harden the operating system to reduce the risk against tools like Mimikatz. TechNet has a great article on how to make the Local Security Authority (LSA) a protected process, by using a security hardening technique that has existed since back in the Windows Vista days. By setting the RunAsPPL registry key for the LSA, you set it up to prevent code injection that could compromise the credentials, which is essentially what Mimikatz does. One suggestion I have beyond this TechNet article is to leverage UEFI secure variables on startup, which prevents an attacker from being able to remove this protection and restart the computer. An attacker would have to gain physical access to the system and have the appropriate access to adjust the UEFI settings before they could remove the process armoring.
NOTE: One word of caution though if you harden LSA. When you make something a protected process, the process must be properly code signed. This means that if you use legitimate code that ties into an LSA like a smartcard driver or credential provider, they too must be signed. Otherwise, they will not be authorized to work with the LSA. So make sure you test this scenario against all of your authentication use cases.
Prevent credentials from remaining in-memory when connecting remotely
When you log on interactively to a computer using the Remote Desktop Protocol (RDP) you end up leaving your credentials in memory on the target system. With Windows 8.1 (and now recently backported to Windows 7) Microsoft added a new capability with a goal to reduce this risk called the Restricted Admin mode which you can enable in mstsc.exe using the /restrictedadmin switch. When you use this switch, instead of sending a user credential to the target it uses your Kerberos TGT to get a ticket to connect as the computer account. I’ve actually heard some people call this "Kerberozed RDP". If you look closely what it’s really doing is using a Kerberos ticket through the network logon process instead of using a password on interactive logon. So it’s more like accessing a file share (but over RDP), than it is an interactive logon you see where you get a password prompt. In fact, when you use this switch you don’t get prompted for a password at all.
There is an interesting backstory to this approach. It was originally introduced to help battle pass-the-hash attacks by preventing the storage of credentials in memory. However, using it with Kerberos tickets makes it ironically vulnerable to the very same attack vector they were trying to plug up. Now you can use pass-the-hash with RDP. Some security experts question if this approach has any real value. I’d argue that this is a security tradeoff that is inherent to the authentication model in Windows. Regardless, a recent Windows update pushed a fix that disables the RDP Restricted Admin feature by default. If you want to use this approach, you need to go back in and re-enable it. You can find more information about this in the Microsoft Knowledge Base article KB2973351.
So why even talk about it if it’s disabled? Most of Microsoft’s guidance on protecting credentials continue to recommend this approach (including recent presentations and videos), even though the security community and Microsoft security itself have decided it’s not something that should be on by default. In actual fact, the Windows 7 backport only had a subset of the fix applied to allow for the invulnerable client mode without exposing the pass-the-hash server mode bits, making it safer. So if you are using Windows 7 and not Windows 8.1 it’s a reasonable option and actually positions you to be better protected than Windows 8.1.
Leverage protected users and control privileged users
A new Active Directory Security Group called Protected Users was introduced in Windows Server 2012 R2. Members of this group are afforded additional protections against the theft of their credentials during the logon process. People assigned to this group cannot use NTLM, digest auth, or CredSSP, which are the typical methods where credentials remain in memory and can be stolen. It also strengthens how Kerberos functions in both the encryption protocols used and the TTL for Ticket Granting Tickets (TGT). Instead of the default of 10 hours it’s reduced to 4 hours, which can be further reduced in time if you configure this with Authentication Policies and Silos. The result is the prevention of credential residue for hashing while reducing the window of exposure of a Kerberos ticket, all while strengthening it at the same time.
Now the Authentication Silos I just mentioned are rather interesting. They allow you to create bastions to restrict how and where credentials can be used. If you have a Windows Server 2012 R2 domain, you can apply Authentication Policies and Silos to help isolate users and/or resources, which allows for custom ticket lifetimes and restricts which users and service accounts can be used. A great place to use this is to isolate access to your domain controllers (DCs) where you rarely need people to have direct access to the system. An example might be to create a "DC Lockdown" Authentication Policy with a ticket lifetime of 1 hour which is set with a condition to only allow users to access it from "Silo" computers. Then you can create a "DC Lockdown" Authentication Silo and assign the policy you just created and set the members to be your tech admin (for example, Alice) and her PC (for example, Alice-PC). See where we are going with this? You can prevent account logon to the DC by anyone but Alice from her PC. So even if someone somehow stole Alice’s credentials, they couldn’t use them to log on to the DC interactively. This is extremely useful against attacks in which credentials are exfiltrated through tools like the Windows Credential Editor (WCE) where they can dump your Kerberos tickets and use them later for pass-the-ticket attacks. If you want to learn more about Authentication Policies and Silos there is a great article on TechNet you should check out.
Summary
I don’t know if you noticed, but I spent a lot of time in this article discussing mitigation strategies to avoid having credentials stored in the first place, and on hardening the environment so that if a credential is stolen you can reduce the impact on the resulting attack surface. Back in 2006 Bill Gates felt that Microsoft could lay the foundation to eliminate passwords once and for all. That couldn’t materialize as these credentials are just far too prevalent in our systems. Instead, Microsoft started to find ways to reduce the credential footprint to begin with, and then further reduce the credential residue that’s left over so attackers have a harder time leveraging it.
So where do we go from here? Start by running your logon session and applications as a standard user. Leverage delegated Administrator accounts with the least privilege needed to conduct the work you are tasked with. Don’t allow local accounts to connect over the network. When you have to use stronger credentials with higher permissions to do work across the network, consider where you do that, and ensure you harden the processes like LSA on your servers so you don’t leave too much credential information behind and don’t allow untrusted code to look at what’s left. Log off your sessions and don’t simply disconnect. Deploy Authentication Silos and harden the inner rings so that only the accounts required to access those services are authorized to do so, from computers authorized to do so. And above all, start treating your credentials like you do your underwear. Change them frequently. Never share them. Never leave them lying around. And they should be sexy. Oh wait… you are in IT, so maybe not. Let’s go for they should be mysterious and hard to figure out. And the longer the better. Especially on those cold nights when you are called in to deal with unauthorized access because someone else didn’t follow this advice.
Dana Epp is the Principal Architect – Security, Identity & Access Management at Kaseya, where he focuses on the architecture and security of the next generation identity and access management platform for cloud-based IT management. He has spent the last 25 years focusing on software security and has been awarded the recognition and designation by Microsoft as an Enterprise Security MVP for the past ten years.
| | | | | This Month's Security Bulletins | | | | | | January 2015 Security Bulletins
| | | January 2015 Security Bulletin Resources:
| | | | | Security Events and Training | | | | | | Protecting corporate data with Enterprise Mobility Suite
Friday, January 23, 2015 – 10:00 AM Pacific Time
Explore some of the feature in Azure Rights Management (Azure RMS) that allow IT departments to enforce rights management when sharing company documents both on premise and in the cloud.
Endpoint Zone: Episode 4
Hear directly from Corporate Vice President, Brad Anderson (that means he runs engineering) about the biggest month yet in Microsoft Intune releases. You’ll hear about the Intune Secure Browser, about Exchange on-prem and Office 365 conditional access and other ground-breaking new features.
Microsoft Virtual Academy: Enterprise Mobility Suite Training
Get free technical training, direct from Microsoft experts from inside and outside of Microsoft. Here is a list of courses currently available to help you get up to speed on the security capabilities of the Enterprise Mobility Suite:
| • | Corporate Apps Anywhere, Anytime with Microsoft Azure RemoteApp – Learn how to provide access to corporate applications from anywhere, on any device, and how to centralize and protect corporate resources on the reliable Azure platform. | | | | • | Securing Your Configuration Manager Infrastructure with Role-Based Admin – Role-based administration allows mapping of administrator organizational roles to security roles, and this course shows you how. It also covers how hierarchy-wide security is managed from a single console and how Role-Based Administration is global data. Get details on how administrative segmentation interacts with security roles, plus what types of objects you can see and what you can do to them. Finally, explore Security Scopes and Collection. | | | | • | Expanding Office 365 with Enterprise Mobility Suite – Learn how to provide access and protections to your users, and explore the enterprise management features you'd expect from any enterprise mobility management solution. | | | | • | Taming Android and iOS with Enterprise Mobility Suite – Get an informative, high-level, and demo-focused look at new enterprise mobility capabilities that make recovery, security, and identity management easier and more flexible. Explore balanced, people-centric (yet highly secure) mobile device management (MDM) policies, and learn how they work with tools you're already using, like System Center Configuration Manager and Microsoft Intune. |
| | | | | | | | | | | | | | | | | microsoft.com/about/twc | Trustworthy Computing | | | | | | | | This is a monthly newsletter for IT professionals and developers–bringing security news, guidance, updates, and community resources directly to your inbox. If you would like to receive less technical security news, guidance, and updates, please subscribe to the Microsoft Security for Home Computer Users Newsletter.
© 2014 Microsoft Corporation Terms of Use | Trademarks
Microsoft respects your privacy. To learn more please read our online Privacy Statement.
If you would prefer not to receive the Microsoft Security Newsletter from Microsoft and its family of companies please click here. These settings will not affect any other newsletters you've requested or any mandatory service communications that are considered part of certain Microsoft services.
To set your contact preferences for other Microsoft communications click here.
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA | | | | | | | | |
