Applocker Resources

NSA Applocker Whitepaper

https://github.com/nsacyber/AppLocker-Guidance

GitHub - microsoft/AaronLocker: Robust and practical application control for Windows

Disabling UAC Remote Restrictions to Limit Credential Exposure

Did you know UAC settings affect remote login privileges? Over the years I've bumped into this and never took the time to fully understand what was happening. I'm writing this post as a quick reference for myself and also to propose a counterintuitive way to limit credential exposure.  Will Schroeder (@harmj0y) wrote an excellent post in 2017 where he laid out some misconceptions and answered a lot of questions about pass-the-hash and how UAC remote restrictions affects remote logins. Based on Will's post and a few Microsoft articles, I've put together a quick chart showing how UAC affects remote logins when using different accounts.

Note: This chart assumes UAC is enabled via HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA

Using the Built-in Administrator (RID 500) for Remote Administration

By default the built-in administrator (RID 500) account connects with full administrative privileges, meaning that UAC Remote Restrictions are not applied. However, if HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken is enabled (set to 1), the RID 500 account is enrolled in UAC protection. The Group Policy setting for this is "User Account Control: Admin Approval Mode for the built-in Administrator account" and it is disabled by default. Microsoft has a good article that describes UAC Group Policy settings and the corresponding registry keys here.

Using a Domain Account That is a Member of the Administrators Group for Remote Administration

UAC remote restrictions aren't applied to domain users. If the account is in the Administrators group on the target, full administrator rights will be granted and UAC is disabled for that session.

Using a Local Admin (Non RID 500 SAM account) for Remote Administration

By default, a non RID 500 local admin will not connect as a full administrator, has no elevation potential, and cannot perform administrative tasks. In order to administer the workstation the user must interactively login. However, if HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy is enabled, all local users connecting remotely are granted full administrative rights.

So why would you possibly set this registry entry?

Will says in his post, "So why would you possibly set this registry entry?" in regard to LocalAccountTokenFilterPolicy, which effectively disables UAC remote restrictions. Well, I think there are a couple scenarios where we can use this setting to actually limit credential exposure. Disabling UAC remote restrictions with LocalAccountTokenFilterPolicy is a bad idea if you have local admin accounts with the same passwords across the enterprise. When an attacker lands a foothold and finds the combination of shared local admin creds and disabled UAC remote restrictions, they'll be able to use the credentials to move laterally and it'll be game over quickly. 

However, by now we should know better than to use the same credentials for local admin accounts. Microsoft LAPs is one solution. If you're setting unique local admin passwords, once exposed they're useless on other systems. Another control that I'm a big fan of, is to isolate user systems from each other via Windows Firewall rules or other means. Ideally, a combination of such controls would be implemented in case one were to fail. If you're implementing controls like these, disabling UAC remote restrictions doesn't have much impact. Local admin accounts will be able to remotely perform administrative tasks. If local admin credentials are compromised, they're only good on the compromised system. An attacker can't use the credentials to login to another system.

Let's flip this concept around in an attempt to use this to our advantage. What are some situations in which using local admin credentials could be beneficial? How about patching, running backups, deploying software, or running vulnerability scans? Many times these tasks are being run via privileged domain accounts. Depending on how each application logs in, these credentials may be left behind on every machine that's accessed. When an attacker lands a foothold, we have the same credential exposure problem we had with local accounts. If we instead ran these tasks with unique local admin credentials and disabled UAC remote restrictions in order to do this, we're limiting our exposure. This may make credential management more difficult, but I find it manageable. Instead of using an all-powerful account and spraying those credentials everywhere, we're use local admin accounts to limit our exposure. This approach may not scale to large environments, but for small/medium networks it has worked for me. Another way to limit exposure would be to use an account that is a member of the Protected Users group. This would force Kerberos and only leave a ticket with a short lifespan on the system; however, this unfortunately seems to break the functionality of some admin tools. 

I see this especially useful not so much for workstations, but for servers. Particularly for scanning and deploying patches and backup job credentials. For workstations, I prefer to isolate user systems. That way deployment credentials are only good from admin subnets and servers used for patch management, vulnerability scans, etc.  You could use this strategy for workstations as well, and some applications like PDQ Deploy integrate with Microsoft LAPs to make credential management easier. 

What are your thoughts on this? As always if I missed anything or you have something to contribute, please comment below. 

File Extensions to Block at Email Gateway

I've combined my file extension block list for email gateways with @HackerHurricane's from his Slideshare here, @cyb3rops list from his ransomware prevention document here, and Microsoft's list from here. Let me know if you have more to add.

.386, .ace, .acm, .acv, .ade, .adp, .adt, .ani, .app, .arc, .arj, .asd, .asp, .asx, .avb, .ax, .bas, .bat, .bin, .boo, .btm, .cab, .cbt, .cdr, .cer, .chm, .cla, .cmd, .cnt, .cnv, .com, .cpl, .crt, .csc, .csh, .css, .der, .dll, .drv, .dvb, .email, .exe, .fon, .fxp, .gadget, .gms, .grp, .gvb, .hlp, .hpj, .ht, .HTA, .htlp, .htt, .inf, .ini, .ins, .iso, .isp, .its, .jar, .jnlp, .job, .js, .jse, .ksh, .lib, .lnk, .mad, .maf, .mag, .mam, .maq, .mar, .mas, .mat, .mau, .mav, .maw, .mcf, .mch, .mda, .mdb, .mde, .mdt, .mdw, .mdz, .mht, .mhtm, .mhtml, .mpd, .mpt, .msc, .msh, .msh1, .msh1xml, .msh2, .msh2xml, .mshxml, .MSI, .mso, .msp, .mst, .nws, .obd, .obj, .obt, .obz, .ocx, .ops, .osd, .ovl, .ovr, .pcd, .pci, .perl, .pgm, .pif, .pl, .plg, .pot, .prf, .prg, .ps1, .ps1xml, .ps2, .ps2xml, .psc1, .psc2, .pst, .pub, .pwz, .qpw, .reg, .sbf, .scf, .scr, .sct, .sfx, .sh, .shb, .shs, .shtml, .shw, .smm, .svg, .sys, .td0, .tlb, .tmp, .torrent, .tsk, .tsp, .tt6, .url, .vb, .vbe, .vbp, .vbs, .vbscript, .vbx, .vom, .vsd, .vsmacro, .vsmacros, .vss, .vst, .vsw, .vwp, .vxd, .vxe, .wbk, .wbt, .wiz, .wk, .wml, .wms, .wpc, .wpd, .ws, .wsc, .wsf, .wsh, .xbap, .xll, .xnk

Deploy Credential Guard - Windows 10

Credential Guard is an awesome feature in Windows 10 that is designed to prevent credential theft even on a system that is completely compromised. I think it's safe to say we can thank Benjamin Delpy (@gentilkiwi) and others like Chris Campbell and Skip Duckwall for the advent of Credential Guard. Ben's tool, Mimikatz, as well as Chris and Skip's Pass-the-Hash research definitely brought this issue into the spotlight and put additional pressure on Microsoft to put some R&D into the problem. 

Credential Guard uses what Microsoft calls "Virtualization based security" to isolate credentials so that malware or attackers with admin privileges can't view or extract them. For more information on why this is so important see my previous post which links to my Derbycon talk. TLDR; When (not if) one of your systems gets compromised, attackers look for credentials and move around laterally until they get what they want. Without Credential Guard it is trivial to view credentials that Windows stores in memory. Depending on the version of Windows these credentials may be in plaintext, hashed, or in the form of a Kerberos ticket.

For example, here is the output of Mimikatz on a Windows 10 system running as a local user and not joined to a domain:

Here you can see the local user's hash that is stored in memory. If this was Windows 7, by default you would see the actual password in plaintext. Now lets look at the output when Credential Guard is enabled:

But wait, it looks like the NTLM hash is still accessible in memory? I confirmed with Benjamin Delpy that this is indeed the case when running Windows 10 LTSB 2015 with a local account. He said this has been fixed in the Anniversary Update so this shouldn't be the case when running LTSB 2016 or the latest Windows 10 CSB. I joined the machine to a domain and on the results were what I originally expected with no credentials accessible:

Configuring Credential Guard

So how do we turn this on? The first thing you need to consider is the prerequisites, which vary depending on the version of Windows 10. At a minimum, you'll need:

• 64-bit CPU with virtualization extensions such as Intel VT-x or AMD-V
• TPM 1.2 or 2.
• UEFI firmware with Secure Boot enabled
• Windows 10 Enterprise, Education, 2016 Server or Enterprise IoT

You can enable Credential Guard via GPO, registry, or with a Microsoft provided Powershell script; however keep in mind the prerequisites must already be in place for Credential Guard to be successfully enabled. If the system didn't have Secure Boot enabled when Windows was installed, you'll have to enable Secure Boot and re-install Windows before Credential Guard will work. On my list of things to do is to find a way to poll systems remotely (probably with Powershell) and output a report on Credential Guard status. Also notice Credential Guard can't be run on Windows 10 Pro. In my mind Credential Guard and Device Guard are the primary motivating reasons to buy Enterprise.

For initial testing, my preferred method of enabling Credential Guard is with the DG_Readiness Powershell script from Microsoft which you can currently find here. This tool allows you to verify a system has the required prerequisites, enable or disable Credential Guard or Device Guard or both, and check to see if they are enabled/running. Run it with the -Capable flag to check the prerequisites:

Don't worry if you see HSTI Validation failed. I'm not exactly sure what this means but it doesn't seem to affect Credential Guard. If you see any other errors in red you'll need to fix those before you can enable Credential Guard. If you don't see any other errors you can run the Readiness Tool with the -Enable flag which will enable both Credential Guard and Device Guard. I ran into an issue when enabling CG this way where some applications wouldn't start because of a "digital signature" error. Running the Readness Tool with the -Disable -DG flags fixed the issue by disabling Device Guard. I assume this had to do with Device Guard being enabled but no configuration for it. Because of this issue, I'd recommend enabling Credential Guard with the -Enable -CG flags as shown:

When the system reboots Credential Guard should be running. You can verify this with the Readiness Tool and the -Ready flag or by running msinfo32.exe. This is what they should look like:

Credential Guard Configured But Services Not Running

When running Windows 10 LTSB 2016 or CSB I've ran into an issue where in msinfo32.exe it appears Credential Guard is configured, but the services are not running. I'm not sure what causes this, but the workaround below worked for me.

• Ensure all prerequisites are in place on the system
• Configure Credential Guard with the Readiness Tool
• After a reboot msinfo32.exe shows Credential Guard configured, but services not running
• Disable Secure Boot in the BIOS
• After a reboot msinfo32.exe shows Credential Guard configured and oddly services running even though Secure Boot is disabled
• Re-Enable Secure Boot
• After a reboot msinfo32.exe shows Credential Guard configured and services remain running

Update - 7-11-17

Ran into this again on an HP Prodesk 600 G1 SFF and the workaround above didn't work. When I looked at tpm.msc it showed "TPM Not Ready". I initialized the TPM from tpm.msc, rebooted, and had to confirm a BIOS message to initialize the chip. I then disabled Credential Guard and re-enabled it with the readiness script and then Credential Guard Services showed "Running" in msinfo32.exe. 

Other Notes

In my experience you can't image a machine when Credential Guard is enabled.

Additional Resources

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/credential-guard

https://blogs.technet.microsoft.com/poshchap/2016/09/23/security-focus-check-credential-guard-status-with-powershell/

Deploying Privileged Access Workstations - Derbycon Talk and Slides

Here is the recording of my Derbycon talk on deploying privileged access workstations and other ways to limit lateral movement and credential theft. Here are the slides from that talk - http://www.slideshare.net/BlueTeamer/deploying-privileged-access-workstations-paws-66374801.

I'll also be giving an updated version of this talk at Dakotacon 2017. Hope to see you there!

Bitlocker Group Policies - Store Recovery Keys in AD

Below are some screenshots for configuring Bitlocker in both TPM Only and TPM+PIN modes. These policies will also automatically store Recovery Keys in Active Directory in the Bitlocker Recovery tab in Active Directory Users and Computers (ADUC). If you are configuring AD to store Bitlocker recovery keys reference the link in the "Additional Resources" section about verifying your AD schema version.

The policy Interactive Logon: Machine account lockout threshold is set at 10 failed logons and then the machine should reboot into Bitlocker Recovery mode. This helps prevent a brute force attack of the Windows login screen and is definitely a good idea especially when using TPM Only. 

Delegating the Right to View Bitlocker Recovery Keys

You can delegate the right to view Bitlocker recovery keys on a particular OU by giving full control of msFVE-RecoveryInformation objects to a user or group of your choice. Domain Admins are the only group that can view these recovery keys by default. 


Note: To view the Bitlocker Recovery tab in ADUC on Windows 7 you may need to add that feature in appwiz.cpl, but it should be viewable on Windows 10 as soon as the GPO is applied. 

Additional Resources

http://theitbros.com/config-active-directory-store-bitlocker-recovery-keys/

Windows 10 - Is Bitlocker TPM Only Secure Enough?

I’ve spent the last week or so researching Bitlocker as a replacement for a third party whole disk encryption product. Microsoft previously recommended pre-boot authentication as a best practice but with Windows 8.1+ they say the following which I’m starting to agree with after some research:

“In the end, many customers will find that pre-boot authentication improves security only for a shrinking subset of devices within their organization. Microsoft recommends a careful examination of the attack vectors and mitigations outlined in this document along with an evaluation of your devices before choosing to implement pre-boot authentication, which may not enhance the security of your devices and instead will only compromise the user experience and add to support costs.” - https://technet.microsoft.com/en-us/itpro/windows/keep-secure/choose-the-right-bitlocker-countermeasure

I’ve read about different Bitlocker attacks including Cold Boot where they freeze the memory of a running system to extract the contents. It sounds like this is technically possibly the results are very unreliable and highly dependent on type and size of memory, etc.

I also read about the “Evil Maid” attack from 2009 which is mitigated by effectively implementing Secure Boot. Similarly there was some research done by Ian Haken where he takes advantage of a vulnerability in Windows on a Bitlocker TPM Only system by tricking it into authenticating to a domain controller he controls and poisoning the Windows cache. This has since been patched with MS15-122 and MS16-014.

There are also Direct Memory Attacks (DMA) which “allows certain types of hardware devices to communicate directly with a device’s system memory. For example, if you use Thunderbolt to connect another device to your computer, the second device automatically has Read and Write access to the target computer’s memory.” This really isn’t a concern unless your device has a Firewire, Thunderbolt port or similar and if it does you can often disable the port via BIOS. 

My Conclusion

Certainly pre-boot authentication is a more secure setup as it is one more hoop for an attacker to jump through. Pre-boot authentication would prevent DMA, Cold Boot, and the attacks that have since been patched. However, if your devices don’t have ports that allow DMA attacks, TPM Only Bitlocker is probably sufficient for most organizations as long as you ensure Secure Boot is enabled, a Supervisor/BIOS password, and Boot Order is set to only boot to the hard drive. It might make sense to take advantage of the usability benefits of TPM+Only on low risk assets and implement TPM+PIN on higher risk assets. 

_________________________________________________________________________

Below is a good excerpt from this article: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/protect-bitlocker-from-pre-boot-attacks

For many years, Microsoft has recommended using pre-boot authentication to protect against DMA and memory remanence attacks. Today, Microsoft only recommends using pre-boot authentication on PCs where the mitigations described in this document cannot be implemented. These mitigations may be inherent to the device or may come by way of configurations that IT can provision to devices and Windows itself.

Although effective, pre-boot authentication is inconvenient to users. In addition, if a user forgets their PIN or loses their startup key, they’re denied access to their data until they can contact their organization’s support team to obtain a recovery key. Today, most new PCs running Windows 10, Windows 8.1, or Windows 8 provide sufficient protection against DMA attacks without requiring pre-boot authentication. For example, most modern PCs include USB port options (which are not vulnerable to DMA attacks) but do not include FireWire or Thunderbolt ports (which are vulnerable to DMA attacks).

BitLocker-encrypted devices with DMA ports enabled, including FireWire or Thunderbolt ports, should be configured with pre-boot authentication if they are running Windows 10, Windows 7, Windows 8, or Windows 8.1 and disabling the ports using policy or firmware configuration is not an option. Windows 8.1 and later InstantGo devices do not need pre-boot authentication to defend against DMA-based port attacks, as the ports will not be present on certified devices. A non-InstantGo Windows 8.1 and later device requires pre-boot authentication if DMA ports are enabled on the device and additional mitigations described in this document are not implemented. Many customers find that the DMA ports on their devices are never used, and they choose to eliminate the possibility of an attack by disabling the DMA ports themselves, either at the hardware level or through Group Policy. Many new mobile devices have the system memory soldered to the motherboard, which helps prevent the cold boot–style attack, where the system memory is frozen, removed, and then placed into another device. Those devices, and most PCs, can still be vulnerable when booting to a malicious operating system, however.

You can mitigate the risk of booting to a malicious operating system:

• Windows 10 (without Secure Boot), Windows 8.1 (without Secure Boot), Windows 8 (without UEFI-based Secure Boot), or Windows 7 (with or without a TPM). Disable booting from external media, and require a firmware password to prevent the attacker from changing that option.
• Windows 10, Windows 8.1, or Windows 8 (certified or with Secure Boot). Password protect the firmware, and do not disable Secure Boot.

Additional Resources

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/types-of-attacks-for-volume-encryption-keys