Week 1 – Advanced Windows Security Course

Week 1 – Advanced Windows Security Course

This week marks the start of a course I am attending called ‘Advanced Windows Security Course for 2017‘ run by Paula Januszkiewicz from CQURE.  I am looking forward to seeing this course progress and discover various tips and tricks to break into operating systems and how to prevent those vulnerabilities

So who are CQURE?

CQURE was formed in 2008 in Poland and since then has expanded to the rest of Europe, the Americas, Middle East and Asia – as well as opening offices in New York and in Dubai.  Their services range from IT security audits, to penetration tests, solution implementations and customized trainings.  They share their expertise both offline (at seminars and conferences) and online (through videos and blog posts).

So who is Paula Januszkiewicz?

Paula Januszkiewicz (or Paula J for short) is the founder and CEO of CQURE.  Paula has extensive experience in security projects and has conducted hundreds of security analyses (even for government organizations).  Within CQURE she devoted herself to her passions: Penetration Tests, Audits, Architecture Consulting and creating Trainings & Seminars.  Paula delivers training on all things related to security and is a top speaker at many well-known conferences like Microsoft Ignite where I first listened to Paula speak.

What is in store for us?

Week 1 – commencing 28th Nov

Week 2 – commencing 5th Dec

Week 3 – commencing 12th Dec

Week 4 – commencing 19th Dec

Week 5 – commencing 10th Jan

Week 6 – commencing 17th Jan

  • Incident Response & Handling Steps with Microsoft Advanced Threat Analytics & Sysmon
  • Windows Security Summary
Here we go for Week 1!

Windows 10/Windows Server 2016 – Platform Security and Internals

This is module 1 and it was billed as an ‘introduction session’…  Tell you what I was very glad that I had listened to CQURE’s excellent webinars over the past couple of weeks, since it covered a lot of similar content,  but at the end of module 1 my brain was well and truly fried and sometimes struggling to keep up with Paula as she whizzed from topic to topic.

At a high level we covered the following topics:


Logman is a built in tool to manage performance log collection, however it can also show you all of the windows event providers that have been registered.  If you run the following on your machine you will see just how many different event providers are monitoring pretty much everything that goes on
logman query providers
On my pretty vanilla Windows 10 machine there are 1,120 providers registered!


XPerf is part of the Windows 10 SDK, and it provides ‘easy’ ways to gather information from your Windows machine while it is running.  XPerf will be covered in much more detail in a later module, so we didn’t dive too deep into this at this time.


Sysmon is a tool written by Sysinternals and CQURE run it on every machine with some standard filters to remove some of the noise.  It traces literally everything and you can write events to a file that you can then remotely monitor with the likes of SCOM to get real-time alerts.  We’re going to cover this in more detail in a later module as well.

Here is a good basic filter from Paula to get you started
<Sysmon schemaversion="3.10">
    <NetworkConnect onmatch="exclude"/>
    <CreateRemoteThread onmatch="include">
      <TargetImage condition="image">explorer.exe</TargetImage>
      <TargetImage condition="image">lsass.exe</TargetImage>
      <TargetImage condition="image">services.exe</TargetImage>
      <TargetImage condition="image">svchost.exe</TargetImage>
      <TargetImage condition="image">winlogon.exe</TargetImage>
    <RawAccessRead onmatch="exclude">
      <Image condition="image">C:\Windows\Sysmon.exe</Image>
      <Image condition="image">System</Image>

Permission Auditing

Incorrect permissions or ACLs is a very common cause for misappropriation or misuse of equipment.  A good tool is NTFS Permissions Reporter which will show you in table view, tree view (and with the paid version exports filtered results to various file formats) all of the permissions assigned in a folder structure or file share.  Of course there are dozens of similar tools out there and you could potentially write your own with PowerShell or equivalent languages.


Procmon is another tool written by Sysinternals  It allows you to really dig into what a process is doing on the system whether it is acting on the registry, file system, network or a variety of other sources.  The filtering is incredible and once you master it you can find all sorts of issues (and more importantly their resolutions) fairly easily.


PsExec is yet another tool written by Sysinternals (they do write a lot of cool tools)  This one can be used to elevate yourself from administrator to Local System (i=Interactive; s=System; d=Do not wait/open in new window)
psexec -i -s -d
This then allows you to get into ‘secure’ parts of the Operating System such as HKLM\Security (which is where all of your service account passwords are stored for any services running in a user context on this machine, and which the following tool can nicely decrypt for you)


Autoruns is again another tool written by Sysinternals (seriously download the entire suite!)  It shows you all the different places that software can and does hook into in order to start automatically.  It can verify signatures and even compare the image files to an anti-malware site called VirusTotal



A CQURE built tool to literally dump out the service account password from HKLM\Security for a named service.

Group Managed Service Accounts (gMSA)

To avoid secrets being stored in HKLM\Security, Microsoft came up with Group Managed Service Accounts.  These accounts are stored in Active Directory and the password is retrievable only by a defined set of machine accounts (which need the credentials to run a service).  The downside of gMSA is that they don’t work well for clustered services, and there is limited application support for them.  The upside is that they are secure, the password is periodically changed and they’re cool!

Security Descriptor Definition Language (SDDL)

SDDL is the foundation for all things ACL related.  The File System, Registry and Services are all controlled with SDDL.  No I must warn you this language was no doubt written by someone with sadistic tendencies…  Use sc sdshow for services and get-acl for files, folders and the registry.

C:\>sc sdshow VSS

PS C:\> get-acl c:\windows | select -expandproperty sddl
PS C:\>

As you can see, straight forward to read!  Luckily online there are translation services, or you can go to MSDN and manually work out what each piece means.

You can add your own rights to that string and then apply them with sc sdset (services) or with set-ACL (files, folder, registry)

Sensitive Privileges

In Windows that are various user rights or privileges that can be managed with Group Policy or gpedit.msc for the local policy.

User Rights Assignment

Some of these privileges are regarded as sensitive, meaning that they bypass other security controls.  As noted in the audit policy, the sensitive privileges are:
  • Act as part of the operating system
  • Back up files and directories
  • Create a token object
  • Debug programs
  • Enable computer and user accounts to be trusted for delegation
  • Generate security audits
  • Impersonate a client after authentication
  • Load and unload device drivers
  • Manage auditing and security log
  • Modify firmware environment values
  • Replace a process-level token
  • Restore files and directories
  • Take ownership of files or other objects
Out of these the following are granted to the Administrators group by default (NOTE before making any changes to your system please ensure you fully test the implications on your server)
  • Back up files and directories

Allows reading of files and directories even if the user doesn’t have explicit rights.  It is questionable whether Administrators should actually be able to do this, so consider removing this right.

  • Debug programs

Allows you to attach a debugger and gain access to all sorts of privileged data.  Unless you are doing this regularly consider removing this right from Administrators.

  • Impersonate a client after authentication

Allows you to pretend to be any currently logged on user without any further authentication.  Again consider removing this from Administrators.

  • Manage auditing and security log

Allows you to read the security log and manage settings for both.  Generally you would want an Administrator to have this right.

  • Modify firmware environment values

Not really used so much any more, but this right is needed to install or upgrade Windows so probably best to leave it for Administrators.

  • Restore files and directories

Allows you to restore/overwrite any files even if you don’t have explicit rights.  Consider whether an Administrator should need to do this.

  • Take ownership of files or other objects

Allows you to become the owner of any object, after which you would have full control on that object.  Whilst it can be useful for a file server with home drives where users may have full control and accidentally or intentionally remove the Administrator’s rights, consider whether an Administrator should need to do this.

One other right deserves a mention which is Deny access this computer from the network.  If you deny the Built-in Administrator account the right to access this computer from the network then you will thwart Pass the Hash attacks for this well known account.  Of course it presumes that you’re not using the Administrator account for anything.  So worth considering…

Integrity Levels

Integrity levels were introduced in Windows Vista (yes one of only a few good things to come out of Vista, which was unfortunately designed for uni-core processors just before multi-core processors became the norm and the OS simply was not designed for that, anyway subject of a future blog perhaps)  Integrity Levels…  The system has four built in integrity levels namely
  • System
  • High
  • Medium
  • Low

A normal user has integrity level Medium where as Internet Explorer with Enhanced Security has integrity level Low.  Ok but what does this do…  Every file and folder is assigned an integrity level and the OS won’t allow a lower level integrity user to effect a higher integrity level object.   So while IE with enhanced security could write into your AppData\LocalLow folder, it couldn’t write into AppData\Local.  Similarly as a standard user would be prompted before they could write into c:\Windows, since that is set to High integrity level and so needs elevation.

Mic Enum

To see the integrity level you can use a tool such as MicEnum from ElevenPaths and to set the integrity level you can use the built in tool icacls /SetIntegrityLevel.  At this stage not many developers are using integrity level to protect their data but perhaps in time this will become more widely used.

File and Registry Virtualization

Parts of the File System and Registry are now virtualized.  Meaning that even if the user does write into these locations, in reality Windows actually writes somewhere else without the user realising.
For the file system this includes
  • %WinDir%
  • \Program Files
  • \Program Files (x86)

Instead of writing in those locations, Windows actually writes in %UserProfile%\AppData\Local\VirtualStore

For the registry this includes the most part of HKLM\Software which writes to HKCU\Software\Classes\VirtualStore.  You can use reg flags HKLM\Software to check which keys can/can’t be virtualised.

Now the concern with both of these is that programs may trust the above locations thinking that they are well protected, however they could be fooled into reading data that another program as maliciously added in the above locations.

Believe it or not this was not all that was covered in the first session, since we also talked about things like Best Practices for File and AD permissions, auditing Active Directory and more, but it gives you a flavour of the breadth and depth of this course!  We were also given a lab to use plus 12 pages of homework exercises to complete by Thursday (as well as two pages of preparatory reading before the next session)

Attacks on Credentials & Prevention Solutions


Module 2 focused on how credentials are attacked and how to prevent these attacks.  First of all what are credentials?  Credentials are proof of who you are which is verified by a trusted 3rd party.

How and where are credentials stored?

Credentials and their MD4 hashes are stored in a variety of places.  They are all indirectly encrypted with a bootkey, which is a machine specific key used to encrypt credentials.  The bootkey is made up of various components including Data, GBG, Skew1 and JD.  These are all stored in a ‘protected’ part of the registry HKLM\SYSTEM\CurrentControlSet\Control\Lsa.

Ok but it is protected so we should be alright, right?

As an administrator it is trivial to use something like psexec to elevate yourself to system level access which then grants you access.  Also if you can get offline access (ShadowCopy, boot from USB, etc.) then you can access that part of the registry pretty easily too.

Right so now I have the bootkey components, now what do I do with them?

Once you have the bootkey then you can use tools to decrypt

  • Machine Account password (HKLM\SECURITY\Policy\Secrets)
  • DPAPI Master Keys (HKLM\SECURITY\Policy\Secrets)
  • MD4 Hashes from SAM (HKLM\SAM\SAM) and NTDS.dit (config and NTDS on Domain Controllers)
  • Service Account Passwords (HKLM\SECURITY\Policy\Secrets)
  • Cached Logon Data (HKLM\SECURITY\Cache)

Using a tool like mimikatz you can simply extract decrypted credentials from the above using the bootkey components.  Trust me it literally takes seconds!

The above can be used for a variety of Pass-The-* attacks including Pass-The-Hash and Pass-The-Ticket

How to prevent this credential attack

Preventing the above attack requires multiple enforcements.  The following 10 items will go a long way towards hardening your environment against the above attack

  1. Remove the Debug Privilege from everyone
  2. Ensure that user are not local administrators
  3. Local Administrator account should have different passwords on different machines.  At least implement Local Administrator Password Solution (LAPS)
  4. Deploy some form of Code Execution Prevention (Don’t allow tools like mimikatz and similar tools)
  5. Ensure that we have offline access protection (e.g. Bitlocker)
  6. Implement Credential Guard (works only for domain accounts and only in Windows Server 2016+ and Windows 10+ Enterprise Edition)
  7. Deploy Authentication Mechanism Assurance
  8. Implement LSA Isolation -> set the RunAsPPL registry value
  9. Add the local administrator account to “Deny access to this computer over the network”
  10. Restrict the Domain Administrators group to only allow them to log into the Domain Controllers

Virtual Secure Mode (VSM)

VSM protects critical processes from the kernel.  So even if the kernel is totally breached, with VSM Credentials and Virtual Machines could not be compromised.  Without VSM a process running on the host could access privileged areas of any Virtual Machine, which would then allow access to things like credentials and hashes in the same way as the earlier attack pattern.

  1. Enable SecureBoot and UEFI in the BIOS, Enable TPM
  2. Join the machine to a domain
  3. install Hyper-V
  4. Run bcdedit /set vsmlauchtype auto
  5. Enable VSM via a GPO setting (Computer Configuration\Administrative Templates\System\Device Guard\Turn on Virtualization Based Security\Credential Guard Configuration)

VSM is available in Windows Server 2016 and Windows 10 and requires processor virtualization extensions such as VT-X, VT-D.  It is the way the modern operating system protects itself from Pass-The-Hash attacks.


Kerberos tickets are cached on the local machine, by default for 10 hours.  However did you know that these tickets are cached system wide!?  So when I log off and you log on, my Kerberos tickets are still stored in the system and if you’re a local administrator it is straight forward to grab my tickets and inject them into your credentials!

This is easy to prevent by adding a logoff script which runs

klist purge

Cached Credentials

These are not really credentials, they would be more accurately described as Cached Logon Data.  They are stored in HKLM\SECURITY\Cache.  These credentials used to be protected with an algorithm called DCC1 but this is subject to brute force and so in Windows Vista MSDCC2 was introduced to increase the strength of the encryption.  More details about the algorithm can be seen here.  Now you may think ‘no problem I can just set cached credentials to 0 and prevent access with cached credentials.

Unfortunately not…  We can overwrite the cached credentials (or create a brand new entry) quite easily with offline access and mimikatz and it will allow us to log on to the machine as any domain account.   We won’t get rights to any domain resources, nor anything protected with DSAPI though.


Chromepass can be used to view DSAPI protected saved credentials from websites and the likes including decrypted password.  When we are logging on with cached credentials we cannot use DSAPI to decrypt data that was encrypted with a different password.  So this protects critical data from this type of attack.  More DSAPI data can be found in %APPDATA%\Roaming\Microsoft\Protect, these are called master key containers, each containing two keys.  One key is encrypted with your password hash (SHA1 for local accounts, MD4 for domain accounts), the other key is encrypted with the public key of the domain (or local machine for standalone).  For Active Directory the private key is held on each Domain Controller.  With physical access to the Domain Controller it is possible to grab this private key and then use it to decrypt the DSAPI secrets on every single machine.  Now the bad news is that the public/private key certificate is generated when you create the domain and it NEVER expires and cannot be revoked/reissued.

The mitigation for this is to use DSAPI-NG which uses SID protected pfx files for the encryption process.  This is the default on Windows Server 2016 and Windows 10, or as a user you could use something like KeePass to store your passwords (but don’t use Windows Credentials for your KeePass credentials.

Smart Cards

Smart Cards are certificates stored on a device (or in case of a Virtual Smart Card in your certificates container) and it allows you to logon with a pin off a security device.  Creating a Virtual Smart Card is very easy by using the following command (NOTE that in production you would use something more secure)

tpmvscmgr create /name myVSC /pin default /Adminkey random /generate

Now the weakness is that you can use pkinitmustiness to create pre-authentication Kerberos ticket.  This allows you to later on use these tickets to access Kerberos protected resources even though you no longer have the Virtual Smart Card!  So the moral of the story is, just because you’ve taken away a Smart Card from a user does NOT mean that the user no longer has access to your environment!  Always disable the user’s account, do NOT rely on having their Smart Card.