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

Blocking Office Macros via Group Policy

If you're lucky enough to be in an environment where Macro's aren't used much for business purposes, it's a good idea to block them altogether. Using Dave Kennedy's Unicorn tool, Social Engineer Toolkit, or other tools it is trivial to create an Office doc that contains a macro that sends a shell back to the attacker. With Macros enabled, users are sitting ducks. Also, there is quite a media storm lately around Ransomware and some variants are delivered via Office macros.

I recently worked on a project where the client had mostly Office 2010 installed with a few Office 2007 stragglers. They wanted to block Macros altogether, but still allow a handful of employees to run trusted macro documents.

The first thing we did was create a new policy called Macros - Disable VBA for Office with the following settings:

The policy settings above seem to nullify any Trusted Locations within the Office applications. This will be a problem for the handful of users that need to use some trusted macro documents.

To workaround this - you can create a new AD group (Macros - Exempt Users) and add the users that need to open trusted Macros. Then from the Macros - Disable VBA for Office GPO select the Delegation tab -> Advanced -> Add the "Macros - Exempt Users" group -> Check the Deny box for the "Apply group policy" permission.

 Now this isn't ideal because now that handful of users has unrestricted access to open whatever malicious macro they want. To restrict this further, you can create another GPO called "Macros - Trusted Locations for Exempt Users" in this example with the following settings:

These setting disable all Macros, but adds a Trusted Location on the network where macros are allowed to run for the users in the "Macros - Exempt Users" group.


There are other ways to accomplish this and this method doesn't scale very well, but it works great in small environments and could be tweaked to work better in larger environments.


Office 2016

Microsoft also recently released a new feature for Office 2016 called Block macros from running in Office files from the Internet that looks interesting.

KB2871997 - Overview and Resources

KB2871997 was released almost two years ago. I'm a bit ashamed it took me so long to realize all the awesomeness packed inside. Microsoft has really gone above and beyond to backport some of these security features into Windows 7. I talked about one of the features enabled by this update in my previous post.

Below is a quick overview of the features enabled by the update. Below that is a resources sections with all the nitty gritty details.

Update - for an even better overview check out Sean Metcalf's post at adsecurity.org.


KB2871997 Quick Overview

• Protected Users group
• Works well with “Authentication Policies and Silos”
•  Blocks everything besides Kerberos authentication and applies hardening to the Kerberos authentication used (enforces AES encryption).

• Restricted Admin RDP mode
• Can only make Restricted Admin connects to a Win8.1+/2012R2 system
• Seems to be a debate regarding the efficacy of this control
• Some argue it opens RDP up to pass the hash attacks
• I'd love to hear people's thoughts on this in the comments

• New well known SID’s

• LOCAL_ACCOUNT & LOCAL_ACCOUNT_AND_MEMBER_OF_ADMINISTRATORS_GROUP
• Allows blocking local users from logging in remotely
• If you haven't heard about this yet, drop everything and see previous post on implementing it

• Features to help mitigate Mimikatz / WCE type tools
• Cached LSASS credentials removed from memory when user logs off (Mimikatz mitigation)

• Clear-text password, the users NT/LM password hash, and the users Kerberos TGT/Session key

• Removal of clear-text credentials from LSASS

• Prevents every Microsoft SSP in LSASS, besides WDigest, from storing the user’s clear-text password

• Wdigest can be disabled with regedit
• NT hash and Kerberos TGT/Session key still be stored in memory
• Without these, SSO impossible

Resources

Overview of KB2871887 - http://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871997.aspx

Protected Users Group - https://technet.microsoft.com/en-us/library/dn518179.aspx

Restricted Admin - https://www.petri.com/should-i-use-rdp-restricted-admin-mode

 How to Enable Restricted Admin - http://social.technet.microsoft.com/wiki/contents/articles/32905.how-to-enable-restricted-admin-mode-for-remote-desktop.aspx

Good video from Microsoft with demos of Mimikatz, Windows Credential Editor (WCE), Authentication Policies and Silos -
https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B359?format=html5#fbid= 

Excellent Overview and Explanation of KB2871997 - https://adsecurity.org/?p=559