Its Rafal Sosnowski from Dubai Microsoft Security PFE Team. I haven't posted much over the past year so let’s roll. Today I want to explain Bitlocker protector called Auto-unlock.

Auto-unlock feature allows a user to access the data and removable data drives without entering the password every time. It works only while OS drive is encrypted with Bitlocker.

You can enable/disable Auto-unlock protector using:

Command line:

Enable-BitLockerAutoUnlock

Disable-BitLockerAutoUnlock

PowerShell:

manage-bde -autounlock -enable D:

manage-bde -autounlock -disable D:

When you enable Auto-unlock, another copy of Volume Master Key (VMK) gets created on the disk and is wrapped by this protector.

If we query status of the volume, Auto-unlock will be indicated by “External Key (Required for automatic unlock)”. It has the same structure as External Key (another protector which in fact might be placed on USB and loaded from there to unlock the drive – called USB startup key or USB Recovery Key).

That external key used for automatic unlock is stored in the registry of the Operating System. This explains why it requires Operating System drive to be encrypted (otherwise attacker could have offline access to these keys)

Fixed data drives:

HKLM\SYSTEM\CurrentControlSet\Control\FVEAutoUnlock\*

Removable drives:

HKCU\Software\Microsoft\Windows\CurrentVersion\FveAutoUnlock\*

Keys are bound to specific user/computer, so we cannot copy them to another machine and allow access. Specifically, they are encrypted with DPAPI (Data Protection API) using the combination of user name and user password (or computer credentials). I believe there is additional entropy because I was not able to decrypt them using my DPAPI tools.

Additionally Auto-unlock keys for fixed drives are stored in protected registry hive, so the only way to analyze them is to export them from the online registry editor and then take ownership of the key and modify ACLs.

If you want to disable BitLocker on C: drive – system will warn you that all drives that are using auto-unlock need to be decrypted:

So, I recommend deleting these keys beforehand and adding another protector (password, smartcard certificate) so we are not left with Bitlocker Recovery Password only:

Clear-BitLockerAutoUnlock.htm

manage-bde -autounlock -ClearAllKeys C:

I hope it was informative.

Rafal]]> https://docs.microsoft.com/archive/blogs/dubaisec/tpm-owner-password Tue, 28 Feb 2017 23:55:40 GMT https://blogs.technet.microsoft.com/dubaisec/?p=2835 Hello everyone. It’s Rafal Sosnowski from Microsoft Dubai Security PFE Team. Today we will focus on TPM Owner Password – quite misunderstood secret that is usually linked to the Bitlocker.

TPM (Trusted Platform Module) is a small chip on the motherboard (discrete TPM) or part of the CPU implementation (firmware TPM) where we can store secret information (private keys, virtual smartcards, Bitlocker keys etc.). TPM is also responsible for measuring integrity of the platform when used with Bitlocker, Measured Boot or Devide Health Attestation.

To use TPM you need to enable it in the BIOS/UEFI. During this process, special TPM Owner Password gets generated. This password can be later used to reset TPM Lockout state. TPM can go into the lockout state when too many incorrect authorization attempts are made to get access to these secrets. For example, when user enters too many incorrect PINs when prompted by Bitlocker pre-boot authentication or by virtual smartcard.

For older Operating Systems (Windows Vista/Windows 7) TPM had to be manually initialized from the tpm.msc (or from Bitlocker configuration wizard). During that process user had opportunity to save TPM Owner Password to a file.

For never operating systems (Windows 8.1/10) TPM is auto-provisioned – that means TPM is automatically activated after OS installation and in case of failure in repetitive attempts during the OS lifetime (triggered by scheduled task). Windows uses the randomly-generated Lockout Auth to provision the TPM, then destroys the Lockout Auth without ever revealing it to the user. However, depending on the GPO settings shown below, TPM Owner Password can be stored additionally in the registry. This GPO is located under:

Computer Configuration\Administrative Templates\System\Trusted Platform Module Services\

Configure the level of TPM owner authorization information available to the operating system

When GPO is configured to store Full authentication data, TPM Owner password will be stored as “OwnerAuthFull” in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin

When GPO is configured with option “Delegated” or “None” – TPM Owner Password will not be stored additionally in the registry during (auto)provisioning.

Note: “LockoutHash” value has nothing to do with TPM Owner Password.

As said before, TPM Owner Password can be useful when TPM got locked out and in some scenarios, it is important to store it in central and secure location for your computers.

There are 2 ways of doing this:

1) MBAM Infrastructure – MBAM agent (Microsoft Bitlocker Administration and Monitoring) is capable of saving TPM Owner Password from the registry to the MBAM SQL Database. Of course this is for scenarios where we use Bitlocker on the machine and have MBAM infrastructure set up. This also assumes that:

a. TPM Owner Password is stored as “Full” in the registry

or

b. MBAM agent is responsible for initializing and taking ownership of the TPM

2) Active Directory – Windows Clients are capable of exporting TPM Owner Password to computer attributes in AD. This assumes that:

a. Client has connectivity to AD during export

b. GPO “Turn on TPM backup to Active Directory Domain Services” is enabled

Note: In most cases when you install MBAM agent TPM is already initialized automatically by the system. You can disable this behavior via PowerShell cmdlet Disable-TpmAutoProvisioning, clear TPM and let MBAM take ownership of it. When MBAM agent initializes TPM, it will escrow TPM Owner PWD to the SQL Database and delete it from registry, despite of “OwnerAuthFull” value in the registry.

TPM Owner Password in AD

When you initialize TPM from tpm.msc or via Bitlocker wizard in Control Panel, process called tpminit.exe will communicate with TPM and initialize it. During this time, random TPM Owner Password gets generates by leveraging TPM RNG (Random Number Generator).

Now if the GPO “Turn on TPM backup to Active Directory Domain Services” is enabled, your TPM Owner password will be escrowed to one of the attributes in Active Directory:

For Windows 7

TPM Owner password is stored in msTPM-OwnerInformation attribute of the Computer object.

For Windows 8 and above:

TPM Owner Password is stored in the msTPM-OwnerInformation attribute of the TPM object. This object is stored in the TPM Devices container located in the root of your domain.

This attribute is back linked to the Computer object by using msTPM-OwnerInformationForComputer attribute.

For Windows 10 1607 and above:

TPM Owner Password is not stored in the AD at all. Even though you can configure GPO on previous operating system (Windows 8/Windows Server 2012 R2) “Turn on TPM backup to Active Directory Domain Services” or registry keys directly on the client machine:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\TPM\ActiveDirectoryBackup = 1

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\TPM RequireActiveDirectoryBackup = 1

Windows 10 1607 will ignore these values.

Another thing which is worth to mention that GPO

Computer Configuration\Administrative Templates\System\Trusted Platform Module Services\Turn on TPM backup to Active Directory Domain Services

has been removed from ADMX templates in Windows 10 1607 and Windows Server 2016. Thus most of information provided in this article is for pre Windows 10 1607 editions.

TPM object and permissions

TPM Objects is unique for every machine and doesn’t change when you reinstall Operating system. This means when you rebuild/reinstall your machine you might encounter some issues while activating TPM.

For example, very common error is 0x80070005 E_ACCESSDENIED

This error occurs because by default new Operating System (after reinstallation) cannot write TPM Owner Password to the old TPM object. Let’s have a look at the default permissions on msTPM-InformationObject:

1. "Write all properties" for an SID: S-1-3-0 Creator Owner (original computer)
2. "Read all properties" for "Domain Computers" (but no write)

We can check this by going to the TPM object in “TPM Devices” container, select original computer (in our case TABLET) and check Special Permissions.

In order to fix this issue, you need to extend the schema by using LDF file published on the TechNet : “TPMSchemaExtensionACLChanges.ldf” which will change default TPM Object’s ACLs. Unfortunately, only new TPM Objects will be affected as we modify the AD schema but not the existing objects.

If you want to change ACLs of existing TPM objects you can just add "Write all properties" and "Read all properties" for "Domain Computers" to the specific or all msTPM-InformationObjects.

Using TPM Owner Password

If you want to change TPM Owner Password, you need to retrieve current password from the MBAM database or Active Directory and copy it to the XML file between <ownerAuth> and </ownerAuth>. In example below, my TPM owner password is 7O66EMj9LFFRhwfFsw+gVAIVkR8=

<?xml version="1.0" encoding="UTF-8"?>

<!--

This page is a backup of TPM (Trusted Platform Module) owner authorization information. Upon request, use the authorization information to prove ownership of the computer's TPM. Please keep this file in a secure location away from your computer's local hard drive.

-->

<tpmOwnerData version="1.0" softwareAuthor="Microsoft Windows [Version 6.0.5461]" creationDate="2016-07-09T17:41:00-00:00" creationUser="contoso\user1" machineName="Laptop">

<tpmInfo manufacturerId="112233445566"/>

<ownerAuth>7O66EMj9LFFRhwfFsw+gVAIVkR8=</ownerAuth>

</tpmOwnerData>

You don’t need to fill out all other details like computer or user name. TPM.msc will only validate password. So, it is fine if you use shorter syntax:

<?xml version="1.0" encoding="UTF-8"?>

<ownerAuth>7O66EMj9LFFRhwfFsw+gVAIVkR8=</ownerAuth>

Save the file with .tpm extension and then go to the TPM.msc, select “Change Owner Password..”

and then “I have the owner password file”.

Once TPM.msc validates current password you will be able to generate new one.

Few tips:

If you change TPM Owner password manually from tpm.msc this change will be reflected in AD if export is configured via GPO.

If you apply GPO “Turn on TPM backup to Active Directory Domain Services” after TPM has been initialized, Owner Password will not be exported automatically. You will have to use scripts or manually change the password.

Changing or entering TPM Owner Password have a tolerance of 1 failure. After that, option of using password will be locked for 24 hours. This is not the same as “TPM Lockout” which is part of TPM anti-hammering capability.

Remember: starting from Windows 10 1607 we dropped export of TPM Owner password to AD. This (change) is because TPM Owner Password could be retrieved from the registry in some scenarios and be used in offline attacks against TPM anti-hammering. Additionally, most lockouts of TPM come from Bitlocker thus you don’t even have access to tpm.msc to unlock your TPM. When TPM is completely locked by Bitlocker, you are stuck in preboot phase of Windows. So the workflow was not very convenient for both users and helpdesk people.

As always I hope this was informative.

Rafal]]> https://docs.microsoft.com/archive/blogs/dubaisec/digest-authentication Tue, 31 Jan 2017 02:14:40 GMT https://blogs.technet.microsoft.com/dubaisec/?p=2455 Hello again. It’s Rafal Sosnowski from Microsoft Dubai Security PFE Team. Today I will focus on Digest Authentication.

Digest Authentication is a challenge-response authentication protocol used to authenticate users over the network. Challenge/response protocols require an authenticating server to generate a challenge containing some amount of unpredictable data. A client then uses a key derived from the user’s password to encrypt the challenge and forms a response. The server, or a trusted service such as Active Directory, can verify that the user possesses the correct password by comparing the client’s encrypted response to a response generated by Domain Controller based on the credential associated with the user in Active Directory or by the server account database for local users. If the responses match, the user is authenticated.

Digital authentication is very similar to NTLM protocol or basic authentication where a simple challenge-response paradigm is used. In the digest authentication mechanism, the client is presented with a nonce, a randomly generated value sent by the server to the client. The client proves knowledge of the password by computing a keyed hash over parameters sent by the server and parameters generated locally by the client.

Once the server has validated the keyed hash by performing the same computation, it can authenticate itself to the client by computing another keyed hash and returning it to the client. Because the correct keyed hash results can only be created by someone who knows the password, the two parties are assured of the other knowing the password.

The Digest Authentication protocol is designed for use with Hypertext Transfer Protocol (HTTP) and Simple Authentication Security Layer (SASL) exchanges.

HTTP example:

When you open the browser and attempt to connect to the website which requires Digest Authentication, your first connection which is anonymous (frame 58 below) will be refused. The server will send you the Challenge (frame 59) containing nonce, charset that can be used, information about algorithm and the realm name. Also, server signals that it supports channel binding by invoking the following 12 characters in the server nonce: "+Upgraded+v1"

A valid response contains a checksum (by default, the MD5 checksum) of the username, the password, the given nonce value, the HTTP method, and the requested URI. In this way, the password is never sent in the clear.

In the response from the client we also can see cnonce - which is client nonce that contains 128 bits of entropy by using a random-number generator as well as a NC - nonce counter used for replay detection attacks.

Now the server needs to verify the challenge response. It will query the Domain Controller for a user password hash and compute the MD5 hash again on the user name, password hash and the nonce. This information will be encapsulated by the NRPC protocols while querying Domain Controller and will be using method netrLogonSamLogonEx. Once the computation is done, server will compare the result with the received challenge response from the client. If the keyed hash is the same – that means user is successfully authenticated. Note: server doesn’t have to have access to user cleat-text password.

Of course, your server should be configured to require Digest Authentication. For example default installation of Windows Server IIS role doesn’t contain Digest Authentication module. You should install it from the Server Manager first. Once it is installed you can go to the Authentication section in the IIS Management Console and enable it:

If you don’t want to bother with UI, you can do it directly in web.config file by adding the section:

<digestAuthentication enabled='true' />

The realm is set to the domain name of the server by default. This can be overridden at the server by configuration options. The user is prompted and has the chance to override the realm value sent by the server (that is, the user can enter a realm other than the one sent by the server).

From now every request going to the digest.contoso.com will require authentication. User experience will be a little different for Internet Explorer and Edge:

Edge:

Internet Explorer:

SASL Example:

User opens the LDP.exe and perform a BIND to active directory with Digest Authentication.

First the user will initiate the connection without sending any credentials but with information that Digest Authentication should be used:

Server similarly to the HTTP example will send us challenge:

And then we need to answer to that challenge by sending our credentials with nonce and domain name to the server:

Logging:

Assuming proper auditing is configured we can expect following events in the Security Log:

Server side: Event ID 4672

Domain Controller side:

Success (Event ID 4776, error code 0x0):

Failure (Event ID 4776, error code 0xC000006A – bad user name or password)

There are some articles on the Internet that say if you want to use Digest Authentication you have to store your password in Active Directory by using reversible encryption.

There are 2 settings for this:

Global in the Domain Password Policy (GPO):

Or individually on the User account:

This configuration was required prior to Windows 2008 where IIS really required passwords in the clear text from Active Directory to verify the Challenge’s response from the client. However, since Advanced Digest Authentication has been introduced (now there is no differentiation) Web Server can use pre-computed MD5 Hashes of user credentials that are stored in AD.

There are 29 variations of credentials stored as part of Suplemental-Credetntials attribute of user object in Active Directory:

Below is an example of table with MD5 hash for credentials for user “u1” and password: “password”:

1) u1:CONTOSO:password >> B57D463D9044A36BF3283CBEF5B76014

2) u1:contoso:password >>EA3B92F0D84D212CC057E63A81E36244

3) U1:CONTOSO:password >> A109619CE218D1DD95EA94A7D5BD466F

You can review the MD5 w-digest construction logic under: https://msdn.microsoft.com/en-us/library/cc245680.aspx

Kerberos and public key–based authentication offer stronger security guarantees both in terms of initial authentication and subsequent confidentiality and integrity of client/server traffic. The digest authentication mechanism can be used in environments where these stronger mechanisms are not available and can serve for interoperability purposes with multiple vendors, browsers, web servers, and directory services.]]> https://docs.microsoft.com/archive/blogs/dubaisec/impersonation-level-for-mbam Thu, 08 Dec 2016 11:18:06 GMT https://blogs.technet.microsoft.com/dubaisec/?p=2155 Hello everyone. It’s Rafal Sosnowski from Microsoft Dubai Security PFE Team. Today, I am going to solve one of the rare errors that can occur while implementing MBAM infrastructure.

My customer had a problem while accessing both MBAM websites: helpdesk portal and self-service portal. Opening any of them resulted in displaying only text version of the webpage without any graphical user interface:

(Sometimes entire webpage was not loading and showing HTTP error 500.)

When we looked at the details in Fiddler and in Developers panel of Internet Explorer it appeared that all elements except index.html were getting status code 500 – Internal Server Error.

HTTP status code 500 is very general (it means something on the server side went wrong but we don’t know yet what) so decided to install and enable “Failed Request Tracing in IIS” and then reproduced the error.

Logs by default are stored in %SystemDrive%\inetpub\logs\FailedReqLogFiles.

Our logs indicated clearly that there was a problem with impersonation of the account logging to the portal. (0x80070542)

The problem was that customer applied GPO security hardening to their servers which removed IIS_IUSRS group from the “Impersonate a client after authentication” setting (internal name SeImpersonatePrivilege).

This policy setting determines which programs are allowed to impersonate a user or another specified account and act on behalf of the user. If this user right is required for this type of impersonation, an unauthorized user cannot cause a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have created to impersonate that client. (Such an action could elevate the unauthorized user's permissions to administrative or system levels.)

Impersonation is the ability of a thread to run in a security context that is different from the context of the process that owns the thread. Impersonation is designed to meet the security requirements of client/server applications. When running in a client's security context, a service "is" the client, to some degree. One of the service's threads uses an access token representing the client's credentials to obtain access to the objects to which the client has access. The primary reason for impersonation is to cause access checks to be performed against the client's identity. Using the client's identity for access checks can cause access to be either restricted or expanded, depending on what the client has permission to do.

Services that are started by the Service Control Manager have the built-in Service group added by default to their access tokens. COM servers that are started by the COM infrastructure and configured to run under a specific account also have the Service group added to their access tokens. As a result, these processes are assigned this user right when they are started.

IUSRS is a local, empty group that is populated automatically when IIS application pool starts. For example, all the build in AppPoolAccounts and custom accounts used to run the IIS application pools are added there when they start.

Below you can see that my IIS_IUSRS group is empty

but account used to run application pool “contoso\mbam_iis” has that group in its Windows token:

Summary: In order to resolve the issue, add IIS_IUSRS group to “Impersonate a client after authentication” user right assignment.

And enjoy browsing fixed MBAM portals:

Rafal

It’s Rafal Sosnowski from Microsoft Dubai Security PFE Team. Today I will troubleshoot with you one error related to EFS (Encrypting File System).

EFS (Encrypting File System) is a component of the NTFS file system present in Windows starting from Windows 2000. EFS enables transparent encryption and decryption of files by using advanced, standard cryptographic algorithms. EFS uses hybrid cryptography: symmetric key is used to encrypt data; asymmetric key is used to protect the symmetric one. To take advantage of asymmetric cryptography EFS uses certificates: self-signed or issued by Certification Authority (CA).

To encrypt the file just right click on it, select Properties> Advanced > Encrypt contents to secure data

On rare occasion when we try to encrypt file or folder, we might get an error “An error occurred applying attribute to the file: Element not found”

Troubleshooting:

So let’s start with enabling verbose EFS\Debug log in Event Viewer. Go to the Eventvwr.msc and select Application and Services Logs > Show Analytic and Debug Logs. This will add dozens of new and very interesting logs to your MMC, including EFS\debug log.

Enable EFS\Debug log and try to encrypt file again to reproduce an error.

Instantly in the log we will see repetitive errors:

event 277:  try and locate the matching key based on cert hash

event 1:  An API call failed at 2.93.  Error code: 2148081668

2148081668 translates to - CRYPT_E_NOT_FOUND

So at the first glance it looks like certificate or proper private key cannot be found. However, when we look at the personal store using command certmgr.msc we see that multiple EFS certificates are delivered from Certification Authority:

Note: when you don’t see certificate delivered to the user personal store, you can take a look at “Failed Requests” container on the CA server to verify why the certificate request was denied:

In our case certificate was successfully issued and delivered by the CA. Moreover we got more than one certificate because File Properties UI cannot find proper certificate and send additional requests to the CA.

Now verify our certificate in the user store using command:

Certutil – verifystore -v -user my

Among the lines we see that certificate has been issued with next generation cryptographic provider called Key Storage Provider (KSP) and public/private key pair has been generated with RSA algorithm. The problem is that EFS doesn’t support keys from KSP based on RSA.

Provider = Microsoft Software Key Storage Provider

ProviderType = 0

Unique container name: a58f5c5c98486fdb30e11dee7877ce02_042a9558-f6ac-4d95-a6ab-6e99a8c2e2a7

RSA

UI Policy = 0

CERT_KEY_PROV_INFO_PROP_ID(2):

Key Container = te-ContosoEFS-cc8788c8-f9bc-4ab1-a784-7266cb7cb673

Unique container name: a58f5c5c98486fdb30e11dee7877ce02_042a9558-f6ac-4d95-a6ab-6e99a8c2e2a7

Provider = Microsoft Software Key Storage Provider

ProviderType = 0

Flags = 0

KeySpec = 0 -- XCN_AT_NONE

EFS will work with keys generated from KSP based on Diffie-Hellman Algorithm (ECDH):

Provider = Microsoft Software Key Storage Provider

ProviderType = 0

Unique container name: b0e837b6acbbb65ddf5142a288e107ef_042a9558-f6ac-4d95-a6ab-6e99a8c2e2a7

ECDH_P521

ECDH

UI Policy = 0

CERT_KEY_PROV_INFO_PROP_ID(2):

Key Container = te-ContosoEFS-42d4a65d-e55f-411d-9f8e-a026bbbabcd3

Unique container name: b0e837b6acbbb65ddf5142a288e107ef_042a9558-f6ac-4d95-a6ab-6e99a8c2e2a7

Provider = Microsoft Software Key Storage Provider

ProviderType = 0

Flags = 0

KeySpec = 0 -- XCN_AT_NONE

Also EFS will work fine with keys generated in legacy cryptographic providers (CSP) and using RSA algorithm.

Provider = Microsoft Strong Cryptographic Provider

ProviderType = 1

Simple container name: te-ContosoEFS-2adf345e-263e-490a-af3b-d1a86ce54018

RSA

PP_KEYSTORAGE = 1

CERT_KEY_PROV_INFO_PROP_ID(2):

Key Container = 4d85da42c5c12b17ccd2c4833db0e856_042a9558-f6ac-4d95-a6ab-6e99a8c2e2a7

Simple container name: te-ContosoEFS-2adf345e-263e-490a-af3b-d1a86ce54018

Provider = Microsoft Strong Cryptographic Provider

ProviderType = 1

Flags = 0

KeySpec = 1 -- AT_KEYEXCHANGE

So where shall we configure proper cryptographic providers and algorithms for EFS? The answer is of course on the certificate template. Remember don’t select RSA while Key Storage Provider is your cryptography provider or you will face “Element not found” error.

Hope this was informative for you and happy encrypting!]]> https://docs.microsoft.com/archive/blogs/dubaisec/tpm-lockout Sun, 10 Jul 2016 02:47:52 GMT https://blogs.technet.microsoft.com/dubaisec/?p=1995 Hello everyone. It’s Rafal Sosnowski from Microsoft Dubai Security PFE Team. Today, I am going to talk about TPM Lockout state.

TPM (Trusted Platform Module) is a small chip on the motherboard (discrete TPM) or part of the CPU implementation (firmware TPM) which can be used to securely store small amount of information (certificates, private keys, virtual smartcards, Bitlocker keys etc.). That data is completely isolated from HDD and partially from OS thus giving it maximum protection.

To get access to that information from OS level user has to present some kind of authorization value. For example, Bitlocker PIN to get access to the Bitlocker Keys, Virtual smart-card PIN to get access to the certificates and private keys etc.

However, TPM has special anti-hammering logic which prevents malicious user from guessing that authorization data indefinitely. Number of possible PIN failures varies across TPM specification:

• For TPM 1.2 – each vendor has different lockout logic, even different TPM models from the same vendor might have different numbers implemented.
• For TPM 2.0 – specification created by TCG (Trusted Computing Group), clearly states that maximum number of failed attempts should be defined, after which TPM gets locked out. Microsoft defines that maximum number of failed attempts in Windows is 32 and every single attempt is forgotten after 2 hours. This is configured by the Operating System at the time of taking ownership of the TPM

Assuming you failed 32 times to enter correct Bitlocker PIN you will see message saying "Too many PIN entry attempts":

TPM can be locked out by any application / software component that uses keys stored in the TPM and protected by PIN/password. For example, we can produce secure data-blobs, encrypted by the keys generated in the TPM. Access to these keys depending on administrator’s configuration will require or request a PIN:

Other example is use of Virtual Smartcards, where certificate alongside with private key is stored in the TPM. Starting from Windows 8.1 , Virtual Smartcards have their own lockout logic, where user has only 5 possible tries. Still, each attempt will increment the TPM counter by 1, but it is less possible that TPM gets locked out.

If your TPM got locked out, it means it will not accept any authorization data, even if it’s correct (correct PIN).

Now you have 4 solutions:

1) Unlock the TPM using the TPM.msc and TPM Owner Password.

2) Wait some time and enter correct PIN (TPM 2.0 will forget 1 attempt every 2 hours)

3) Wait x hours to completely reset TPM lockout counter (for TPM 2.0: 64 hours)

4) Clear TPM (that means all your data stored in TPM will be lost)

If your TPM is locked, you will see its status in the “tpm.msc” as "TPM is locked out" or “Ready for use with limited functionality”. The second status can appear on virtual TPMs and few hardware TPMs which is a glitch.

Note: “Ready for use with limited functionality” might also mean that TPM has been initialized by the previous operating system. So it is always better to check the status using PowerShell:

Get-TPM

Since Windows 10 (1511) we have added also lockout counters (for TPM 2.0) shown in above screenshot.

To unlock the TPM from tpm.msc you need to be an administrator of the machine and be in possession of the TPM Owner Password. We will talk about TPM Owner Password in details in one of the future posts.

Of course this method will not work when TPM is locked out by Bitlocker PIN (before you get into the Windows). For Bitlocker related lockouts you need to wait as there is no working workflow to unlock the TPM in this scenario, except using other protector, for instance 48-digit Recovery Password to get into Windows.

Some of you probably have already noticed 3 new GPO policies (added in Windows 8) that supposed to influence the TPM build-in anti-hammering logic by introducing some kind of software layer that would accumulate failed PIN attempts before forcing TPM into hardware lockout. Idea is to reduce number of true, hardware lockouts. However, according to my tests these policies don’t work on any of the tested systems (Win8, Win8.1, Win10) so I am trying to get confirmation from our developers what’s going on. Once I get some information I will update this post.

GPO I am talking about can be located in:

Computer Configuration\Administrative Templates\System\Trusted Platform Module Services\

Standard User Individual Lockout Threshold (default: 4)

Standard User Total Lockout Threshold (default: 9)

Standard User Lockout Duration (default 8 hours)

Hope this post was informative for you and I wish you good day.

Its Rafal Sosnowski from Microsoft Dubai Security PFE Team. Some time ago I put together all versions of MBAM (Microsoft Bitlocker Administration and Monitoring) tool into one table. Small disclaimer: It is based on what I have seen in the wild and is not official information from Product Group.

As you can see in above table, some of the version numbers will apply only to client side binaries, some of them only to server side binaries. So it is fine to have client and server components on different version levels (within one major release: 1.0; 2.0; 2.5).

Also older clients (like MBAM 1.0) can still talk to the latest MBAM server (like MBAM 2.5 SP1) however we always suggest to upgrade both client and server side and keep them on most recent version.

Version check:

If you want to check what is the current version of MBAM server side components navigate to the registry:

MBAM 2.5:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MBAM Server

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MBAM Server\Version

MBAM 2.0:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft BitLocker Administration And Monitoring\Setup

If you want to check what is the current version of MBAM agent navigate to the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MBAM

Or go directly to the filesystem and check properties of the agent service’s file which resides by default in:

C:\Program Files\Microsoft\MDOP MBAM

I hope this quick post was informative and if you have any MBAM version not listed here, please let me know and I will add it to the table.

ELAM – Early Launch Anti-Malware is a piece of code that is loaded in the pre-boot environment and is responsible for verification of other drivers before they are loaded into memory. ELAM driver is being called by the Kernel and it reports the status of the driver images: if they are safe or unsafe to load. ELAM driver has been introduced in Windows 8 and is not dependent on UEFI nor BIOS implementation.

The early launch AM drivers are started soon after the NTOS kernel starts.  For each subsequent boot driver, the AM driver receives a callback from the Kernel Plug and Play manager to determine whether the boot driver should be initialized.  The AM driver evaluates the boot driver and must return good, bad, or unknown status of the driver.  Based on the returned classification and defined policy, the PnP manager decides whether to initialize the boot driver.

Classification:

ELAM driver can return status of the boot driver as good, bad, or unknown. This image evaluation is based on the malware signature data stored under: HKLM\ELAM\<VendorName>\. This registry hive is loaded by the winload.exe process at the same time as ELAM driver

Within the key, the vendor will keep blacklists and/or whitelists of the drivers’ images and virus signatures. So far, ELAM cannot detect malware based on the heuristics or malware that has ability to polymorph so it relies on the image hashes and virus signatures.

Each ISV is responsible for updating and verifying its malware signature data for its ELAM driver. When the AM driver is initialized, it should verify the integrity of the malware signature data by validating a digital signature.

The ELAM hive is unloaded after its use by Early Launch Antimalware for performance reasons. If a user mode Antivirus service wants to update the signature data, it should mount the hive file from the c:\Windows\System32\config\ELAM. The storage and retrieval format of these data BLOBs is left up to the Antivirus Vendor, but the signature data must be signed so that the AM driver can verify the integrity of the data.

Defined Policy

When the status of the drivers is returned (good, bad, unknown), system will decide whether load particular driver or not, based on the policy stored in:

HKLM\SYSTEM\CurrentControlSet\Policies\EarlyLaunch\ DriverLoadPolicy

This Policy can be defined manually or via GPO under:

Computer Configuration \ Administrative Templates\ System \ Early Launch Antimalware\ Boot-Start Driver Initialization Policy

If the policy is not configured or disabled the boot drivers determined to be Good, Unknown or Bad but Critical are initialized and the drivers determined to be Bad are skipped.

Driver is marked as critical if internal routine of ELAM driver determines that blocking this particular driver would cause system to halt / bluescreen.

An image is treated as unknown when an error is returned from the initialize image callback or when the signature data doesn’t exist in the registry.

After classification of drivers has been finished and malicious drivers were blocked, the ELAM driver will unload. Anti-Malware engine should be started prior to the early launch AM driver being unloaded. This means that the runtime AM engine should be a boot driver that is verified by the early launch AM driver not a user mode process.

Default Windows ELAM driver:

By default, ELAM driver is provided by Windows Defender and is registered as WdBoot.sys driver. You can find it in %systemroot%\system32\drivers folder.

3^rdparty ELAM drivers:

Microsoft requires that Early Launch Antimalware vendors be members of the Microsoft Virus Initiative (MVI). This membership ensures that the vendors are active antimalware community participants with a positive industry reputation and participate in antimalware initiatives.

For example, if we install Symantec Antivirus, it will register its own ELAM drive called SymELAM.sys:

If you want to register your own ELAM driver for testing purposes, use command:

sc create Elam-Test binpath=%windir%\\system32\\drivers\\TEST-ELAM.sys type=kernel start=boot error=critical group=Early-Launch

ELAM driver signing:

Every ELAM driver has to be signed by Microsoft Code-signing certificate. This certificate has to have special EKU (Extended Key Usage) indicating Early Launch Anti-Malware driver. If the ELAM driver is not signed with such certificate it will fail to load.

Winload checks the signatures of all boot drivers as they are loaded into memory. On 64-bit platforms all boot drivers must have valid signatures, their certificates must chain to a trusted root CA, and their certificates must contain the Codesigning enhanced key usage (EKU) extension. Signing is not required on 32-bit platforms. ELAM drivers are special in that they must be signed by Microsoft, and their signing certificates must also contain a special EKU indicating that it is an ELAM Driver (OID: 1.3.6.1.4.1.311.61.4.1). This is true for both 32-bit and 64-bit platforms.

Additional considerations:

Backup Driver Installation

To provide a recovery mechanism in the event that the ELAM driver is inadvertently corrupted, the ELAM installer also installs a copy of the driver in a backup location. This will allow WinRE to retrieve the clean copy and recover the installation.

The installer reads the backup file location from the BackupPath key stored in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\EarlyLaunch\BackupPath

Disabling ELAM:

Like Secure Boot, ELAM driver can be disabled by the owner of the platform. User can restart the machine and put it into Advanced Restart mode. Just restart your PC using combination of “Shift + Power > Restart” or execute:

Shutdown /r /o /t 0

and follow the menu path: Troubleshoot > Advanced Options > start up Settings > Restart

On next screen you can choose Disable early launch anti-malware protection:

This has been implemented to remediate situations where ELAM blocks some important driver which prevent machine from botting. In this case you can disable ELAM, remove problematic driver and boot your PC normally. The next time you reboot your computer, Early Launch Anti-Malware Protection will automatically start again and continue protecting your computer. To remove the ELAM driver permanently you would have to unregister it from the system.

So to summarize: ELAM has antimalware capabilities and can block drivers from being loaded into memory before they are initialized. ELAM is part of the Microsoft Trusted Boot standard and can mark your drivers with status: good, bad or unknown and then allow or prevent from loading. ELAM can be disabled by the user that has physical access to the computer.

It's Rafal Sosnowski from Microsoft Dubai Security PFE Team. Today I want to talk about Special Groups – feature added back in Windows 2008/Vista but not rarely used by administrators. Special Groups feature lets you audit all logons of the user that belongs to certain group so called “Special Group”.

This is quite useful in environments where we want to be notified every time high privilege account logon to set of computers (for example Domain Admins somehow log on to servers or workstations). We generally recommend against using high privileged accounts on workstations and servers.

This feature assumes that you met two conditions: your user is part of the group you monitor and Audit Special Logon is enabled in Advanced Auditing.

To enable Special Groups feature:

1. Obtain SID of the group you want to monitor:

We can do it using different methods for example PowerShell:

Get-ADGroup “name of your group”

Or older combination of dsquery and dsget commands:

Dsquery group -name “name of your group” | dsget group -sid

BTW: If you want to obtain SID of local user to group, you might execute:

wmic useraccount where name="administrator" get sid

wmic group where name="administrators" get sid

However, users SIDs (nor local, neither domain) cannot be used. This feature works only with group SIDs.

2. Add SID of the Group to the registry

You need to add SID of the group you want to monitor to the registry by adding new String value (REG_SZ) under:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Audit

This string value should be named SpecialGroups and include the SID of the group. If you want to add multiple groups you can separate them using a semicolon character (;). Below I have used Group Policy Preferences to deploy this to all Desktops/Servers but you can deploy it using startup script or SCCM\MDM.

Action type should be “Create” if value doesn’t exist or “Update” if value already exist:

3. Enable “Audit Special Logon”

In group Policy editor go to the Advanced Security Audit Policy Settings and configure Logon-Logoff\Special Logon subcategory to Success or Success and Failure. You can verify it using auditpol command:

Auditpol /get /category:”Logon/Logoff”

From now all logon types: network, local, via RDP will be audited and event ID 4964 will be noted:

In most cases customers will be interested in monitoring high privileged groups like “Domain Admins” or “Enterprise Admins” as well as local group “Administrators”.

If you add SID of local administrators group S-1-5-32-544 to the registry and logon with local account, the event will be audited. However, if you use domain user account which is part of the local Administrators group– the event will not be audited.

For your reference I have created a table that shows when event 4964 will be audited:

You can collect this event ID 4964 using SIEM solution and use alerting to inform your Admins when user with high privileges log on to any computer. Also above feature should be part of auditing strategy in all enterprises.

Rafal

Network Unlock is a relatively new Bitlocker protector (added in Windows 8) that can be used to unlock computers after the reboot without need of entering Bitlocker PIN.

This is very helpful in scenarios where all workstations protected by Bitlocker with TPM+PIN need to be restarted due to monthly maintenance or after power outage. Another scenario is when you don’t want to bother your users in corporate network with PIN prompt but require it when user takes laptop home.

For Network Unlock to work you need to meet some prerequisites mentioned below including having DHCP Server, WDS Server, UEFI capable clients and special certificate deployed by the GPO. Network unlock uses MS-NKPU protocol encapsulated into DHCP packets.

How Network Unlock Works:

The whole process of unlocking the Operating System drive encrypted by Bitlocker with network unlock feature is split into three phases:

Phase 1:

In first phase client that is configured to use network unlock has to obtain valid IP address from the DHCP server. This DHCP request is sent from UEFI firmware not from DHCP client service in the Operating System. We also assume that proper GPO is configured on the client which enables Network Unlock and delivers special certificate used to encrypt message sent in next phase.

Phase 2:

In this phase clients will broadcast MS-NKPU request which is encapsulated into DHCP INFORM packet and is containing Bitlocker key material encrypted with the WDS certificate public key from the GPO. Also this packet will contain 256-bit session key used later to protect the data exchange.

Phase 3:

When Network Unlock server receives the MS-NKPU Request, it will decrypt it with corresponding private key of WDS certificate and send back the Bitlocker Key material encrypted with the session key. Because client generated this session key in previous step, it will decrypt the Bitlocker key material easily. Client now will be able to unlock its drive and allow user to log on to the system.

Prerequisites:

DHCP Server

DHCP server provides IP address to the clients in the pre-OS boot environment. DHCP Server is required when you are using IPv4 and is optional if you are using Ipv6 due to auto configuration with link-local Ipv6 address. Network Unlock on the client uses its linked local address to create DHCPv6 request packet, so it works without configuring a DHCPv6 server. You can configure both DHCPv4 and DHCPv6 scopes on the same machine or on different machines/devices. If you have DHCP and client computers in different subnets you will have to configure DHCP Relay agent on your router.

WDS Server

WDS server as a separate server role or part of the SCCM and is required to provide PXE functionality (Pre-boot Execution Environment). PXE is mainly used to install or boot operating system from the network but in this case it will answer all NKPU requests arriving to the server. Indeed, WDS server is a hosts for special Network Unlock provider which answers these requests.

NKP Provider is added to the server during Network Unlock feature installation and is loaded to memory when WDS service starts. Corresponding event will be also logged in the: Applications and Services Logs\Microsoft\Windows\Deployment-Services-Diagnostics\Debug

Event ID: 24577

[WDSServer/WDSPXE] NKPPROV Provider initialized successfully.

Note: this log is disabled by default. You need to explicitly enable it in the Eventvwr.msc

Also you can verify if provider has been registered successfully under:

HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\

It is also possible to configure list of IPv4 or IPv6 subnets on WDS server, in classless inter-domain routing (CIDR) notation, from which clients are permitted to be unlocked.

Network Unlock Feature

On the WDS server you need to install Bitlocker Network Unlock feature using Server Manager or command line:

Install-WindowsFeature BitLocker-NetworkUnlock

This process will register small DLL (nkpprov.dll) as a separate PXE provider plugged into the WDS server. This provider listens to all DHCPv6/v4 broadcast packages on the network, and will only respond if the package is for Network Unlock. It will not respond to normal DHCP/PXE packets.

Clients

Clients have to be Windows 8 or above with support for UEFI spec 2.3.1. Clients also have to have TPM enabled, activated and with ownership taken by the system. NKPU protocol (which is used by Bitlocker Network Unlock) can work with both wired and wireless networks [ link ], however there are not many platforms supporting PXE/DHCP over Wireless in pre boot environment. As per protocol specification:

The security of this protocol assumes that only a physical local area network (LAN) connection is available when executing this protocol, and that physical connectivity to the LAN is an implicit built-in authentication factor. Note that wireless networks do not offer this security. However, WiFi usage with the NKPU Protocol is acceptable if the user is required to authenticate to the access point when establishing a connection to the NKPU server.

From Bitlocker perspective, so far Microsoft doesn't support Network Unlock over WiFi. There are few reasons for that:

• Wi-Fi signals can be spoofed and the process of provisioning server certificates to clients (laptops) and enabling such network unlock can be vulnerable to man-in-the-middle attack, where attacker can then collect all hard drives keys that unlock all laptop drives and later get access to any stolen/lost laptop from that enterprise.
• Increasing retry logic in the pre-boot process quickly gets into very limited high quality entropy (RNG) we have available to use for session keys to protect unlock traffic against replay attacks. If retries are increased we can expose network unlock to replay attacks.
• Wi-Fi signals can easily spread outside of the physical building boundary and an attacker who stole or found lost laptop can walk to the building (without entering) and unlock it nearby, just by powering it on.

So again, according to Microsoft official protocol specification, NKPU can work over WiFi, however it is very challenging to secure such communication. For example I've never seen an 802.1x authentication implemented in UEFI WiFi network stack . Also, since it is almost impossible to limit boundary of the WiFi, even if we have Access Point authentication implemented, it would be impossible to defend against attacker unlocking stolen laptop just right to premises' fences. So, it might work but it's not supported

Client doesn’t have to have TPM+PIN nor TPM protector configured on the OS drive although it is best practice to use TPM+PIN protector. Network unlock protector is in fact combination of 2 protectors: TPM + certificate as shown in the picture below:

So yes it is possible to use Network Unlock protector without having TPM+PIN added to the OS drive, however in normal circumstances it is recommended to have it.

Certificate

Special certificate with OID 1.3.6.1.4.1.311.67.1.1 (Bitlocker Drive Encryption OID) has to be obtained from the Certification Authority Server* and imported into FVENKP computer store on the WDS server:

This certificate is used to encrypt Bitlocker Key Material sent by client to the WDS server. Only WDS server can decrypt it with its private key and send back to the client.

You can verify if certificate is present using certlm.msc or command line:

Certutil -verifystore FVENKP

*Self-signed certificates are also supported.

GPO Configuration

Above WDS certificate (public key) has to be deployed to all computers that will be using network unlock feature. Simplest way is to use GPO

Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\Bitlocker Drive Encryption Network Unlock Certificate:

or registry: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\FVE_NKP

Also policy “Allow network unlock at startup” has to be configured on all client computers via GPO:

Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Operating System Drives

Network Trace:

If we take a look at the network trace, we see that after obtaining IP address from the DHCP server 10.0.0.10 (DORA process) client 10.0.0.150 sends DHCP Inform packet with Vendor Class ID: Bitlocker. This is a request to Network Unlock Server containing session key, certificate thumbprint and Bitlocker key material encrypted with certificate public key deployed earlier by the GPO.

Bitlocker key materials is concatenated from Option 43 (0x2B) and Option 125 (0x7D) of that packet.

In the response server will send us Bitlocker Key which was decrypted by Network Unlock server private key. To protect this material server will encrypt it with the session key. This is encapsulated into DHCP reply with Opcode: BootReply:

Additional notes:

DHCP v6 can be disabled in some of the UEFI implementations from the UI. If you want to make sure that Network unlock happens only via IPv4 you need to disable IPv6 on the network card of WDS server. Bootmgr code on the client will first try to unlock via DHCPv6 and failover to DHCPv4.

Network Unlock still uses TPM to check integrity of the platform. So if the values in the PCRs (Platform Configuration Registers) have changed due to, for instance: BIOS upgrade, replacement of motherboard, malware in the boot components etc. you will be still prompted for Bitlocker Recovery Password. Entering this password cannot be automated in any way.