Mar 16 2015

Microsoft EMET 5.2 Now Available!

 

Microsoft Security Research and Defense blog posts that Microsoft EMET 5.2 is now available!

Following is the list of the main changes and improvements:

  • Control Flow Guard: EMET’s native DLLs have been compiled with Control Flow Guard (CFG). CFG is a new feature introduced in Visual Studio 2015 (and supported by Windows 8.1 and Windows 10) that helps detect and stop attempts of code hijacking. EMET native DLLs (i.e. EMET.DLL) are injected into the application process EMET protects. Since we strongly encourage 3rd party developers to recompile their application to take advantage of this very latest security technology, we have compiled EMET with CFG. More information on CFG are available at this Visual C++ Team blog entry.
  • VBScript in Attack Surface Reduction: the configuration for the Attack Surface Reduction (ASR) mitigation has been improved to stop attempts to run the VBScript extension when loaded in the Internet Explorer’s Internet Zone. This would mitigate the exploitation technique known as “VBScript God Mode” observed in recent attacks.
  • Enhanced Protected Mode/Modern IE: EMET now fully supports alerting and reporting from Modern Internet Explorer, or Desktop IE with Enhanced Protected Mode mode enabled.

You can download EMET 5.2 from microsoft.com/emet or directly from here.

If you downloaded EMET 5.2 prior to 3/16/2015, download again to fix issues with IE 11.

Feb 18 2015

Interesting KRBTGT Password Reset Behavior

Following up on Twitter conversations (@passingthehash, @scriptjunkie1, gentilkiwi, etc) on the new KRBTGT Password Reset Script and Skip Duckwall’s (@passingthehash) blog post on how KRBTGT password changes work.

Microsoft KB2549833 states that the KRBTGT password is set automatically to a random string when a new password is entered.

This occurs because there is special logic when changing the password for krbtgt. While the Active Directory Users and Computers (dsa.msc) snap-in allows you to enter a password, it won’t be used when changing the password. Instead, the Active Directory creates a very long string of random bits to use as the password.

Benjamin Delpy posted on Pastebin the RPC calls performed when the KRBTGT password is changed.

[rpc call]
SamrSetInformationUser
SampStoreUserPasswords
SampRestrictAndRandomizeKrbtgtPassword
SampGenerateRandomPassword
CDGenerateRandomBits

Thanks to the information in the links above, we know that after setting the KRBTGT password to a known value, the DC automagically changes the password to a system-generated password.
More information on KRBTGT.

Skip wonders in his post (linked above) what would happen if an Active Directory admin changed the KRBTGT password manually on several Domain Controllers to “speed up” replication. Any AD admin worth his/her salt knows this a *bad* idea.

I decided to try this out in an isolated lab environment with 4 DCs (Windows Server 2008 R2 DFL):

  • DC01: Windows Server 2008 R2 [5 FSMOs]
  • DC02, Windows Server 2008 R2 (not patched)
  • DC04: Windows Server 2012
  • DC05: Windows Server 2012 R2

I wrote a quick PowerShell script that stops all Domain Controller replication in Active Directory, changes the KRBTGT password to a known value (“Password99!”), and restarts replication. After re-enabling replication across all DCs, I forced replication to ensure all DCs were communicating correctly. I was able to successfully log on as a user and connect to the SYSVOL share on each Domain Controller.

The result:

The KRBTGT password hash is the same as the Administrator account password which is set to “Password99!”
This didn’t change even after rebooting all DCs.

I ran through this test twice with the same result. It seems that at least in my isolated lab testing that changing the KRBTGT password when replication isn’t working can result in the password not being changed by the system. Setting the KRBTGT password with replication occurring normally results in a random, system-generated password.

NOTE: This is an isolated lab test and may not be representative in a lab environment.

Password Hash on DC04 after manual KRBTGT password change to “Password99!” before AD replication is re-enabled.

KRBTGT-PostPasswordChange-DC04

 

Password Hash on DC05 after manual KRBTGT password change to “Password99!” before AD replication is re-enabled.

KRBTGT-PostPasswordChange-DC05

Password Hash on DC01 after manual KRBTGT password change to “Password99!” before AD replication is re-enabled.
What’s interesting is that the password is the same as what’s set (this merits further investigation).

KRBTGT-PostPasswordChange-DC01

Password Hash on DC02 after manual KRBTGT password change to “Password99!” before AD replication is re-enabled.

KRBTGT-PostPasswordChange-DC02

After AD replication is re-enabled, this is what the KRBTGT password converged to.
 KRBTGT-PostPasswordChange-ReplicationConvergence

Here’s a comparison of the repadmin output for the KRBTGT account password attribute (unicodePwd) after the password change.
The first block shows that the originating DC for the password change is the DC targeted. Since Replication is disabled, the password change doesn’t replicate out.
The second block shows that the password change on DC01 trumped the others.

KRBTGT-PostPasswordChange-ReplicationStatus

The AD credential dump shows the auto-generated password hash is different from the Administrator one (before replication).

KRBTGT-Password-After-Change

After full replication, the KRBTGT password hash is the same as the Administrator password hash, meaning that the password is the same.

 

KRBTGT-PostPasswordChange-AD-CredsDump

 

Feb 11 2015

MS15-011 & MS15-014: Microsoft Active Directory Group Policy (GPO) Vulnerabilities Patched

On February’s Patch Tuesday (2/11/2015), Microsoft released two patches that fix issues with the way Group Policy is processed by the client. Interestingly enough, one of these vulnerabilities (MS15-014) makes the other one (MS15-011) not only feasible, but quite capable.

The Attack Scenario:

  • An attacker leverages the vulnerability described in MS15-014 to prevent/stop Group Policy settings from being applied, including SMB Signing which enables the client to verify a valid DC is providing the Group Policy data.
  • The attacker successfully prevents legitimate Group Policy settings from being applied, so they revert to default which disables SMB Signing.
  • This enables the attacker to move onto phase 2: trick the target computer to connect to an attacker machine instead of a Domain Controller. This can be performed through several methods, though ARP cache poisoning is the one Microsoft specifically calls out (in a coffee shop scenario).
  • The target computer reaches out to the Domain Controller when a user logs on to run the logon script: \\domain.com\NETLOGON\logon.bat
  • The target computer connects to the attacker’s hosted share instead of the Domain Controller and runs the file provided by the attacker’s system. Either the attacker configures the same shares and files on the attacker system or use a custom SMB server that responds to any request with files of the attacker’s choice.
  • The target computer runs the attacker’s file which executes code as the local user (logon script) or as System (Group Policy). The attacker has now executed code on the target system without any obvious event which would trigger an alert (other than perhaps an IDS triggering on ARP cache poisoning).

The Microsoft Security Research & Defense article, “MS15-011 & MS15-014: Hardening Group Policy“, calls out the “coffee shop” attack scenario where the user’s domain-joined computer attempts to connect to a Domain Controller to execute a file. Since the attacker can re-route communication to a system of their choosing, the target computer can be exploited leveraging both vulnerabilities.

NOTE:
While the coffee shop scenario described by Microsoft is the most likely – i.e. a roaming user on a laptop connected to an untrusted network (WiFi), it is possible for this to work on a corporate LAN/WAN.
In order to perform this attack, the attacker must be able to control a computer on the same network as the target computer and be able to redirect the target’s traffic to the attacker controlled system (instead of the valid Domain Controller).

Additionally, even if the patch has been applied, if SMB signing is not enabled, an enterprise may still be vulnerable.

MWRInfoSecurity has a write-up on exploiting this vulnerability on a corporate LAN.

Attack Mitigation:

  • Ensure roaming users (laptops) have VPN software installed and required for connections outside of the corporate network. This provides some protection, but an attacker controlled DNS may still be able to force traffic destined for a corporate DC to go outside of the VPN tunnel.
  • Apply the patches to all domain-joined computers (sorry Windows 2003, no soup for you!) [Windows 2003 is End-of-Life, support-wise in July 2015, right?]
  • Configure Group Policy to apply to all domain-joined computers with the following minimum Hardened UNC Paths (see below for step-by-step configuration):
    • \\*\NETLOGON    RequireMutualAuthentication=1, RequireIntegrity=1
    • \\*\SYSVOL    RequireMutualAuthentication=1, RequireIntegrity=1

Continue reading

Feb 03 2015

Configuring Two-Factor Authentication for Web (Cloud) Services

Don’t want your web (cloud) account password to get hacked?
Enable Two-Factor Authentication (aka two-step verification)!

Google Account:

  • Visit this site and follow the instructions to configure your cell phone as a second factor

Whenever you sign in to Google, you’ll enter your password as usual.

Then, a code will be sent to your phone via text, voice call, or our mobile app. Or, if you have a Security Key, you can insert it into your computer’s USB port.

Twitter:

  • Follow the instructions here.
  1. Visit your account settings page.
  2. Select “Require a verification code when I sign in.”
  3. Click on the link to “add a phone” and follow the prompts.
  4. After you enroll in login verification, you’ll be asked to enter a six-digit code that we send to your phone via SMS each time you sign in to twitter.com.

 

Office 365:

Multi-factor authentication increases the security of user logins for cloud services above and beyond just a password. With Multi-Factor Authentication for Office 365, users are required to acknowledge a phone call, text message, or an app notification on their smartphone after correctly entering their password. Only after this second authentication factor has been satisfied can a user sign in.

Multi-factor authentication has been available for Office 365 administrative roles since June 2013, and today we’re extending this capability to any Office 365 user. We’re also enhancing the capabilities that have been available since June. We’re adding App Passwords for users so they can authenticate from Office desktop applications as these are not yet updated to enable multi-factor authentication. And we’re enabling users who are authenticated from a federated on-premises directory to be enabled for multi-factor authentication.

This addition of multi-factor authentication is part of our ongoing effort to enhance security for Office 365, and we’re already working on Office desktop application improvements to Multi-Factor Authentication for Office 365, which we’ll introduce later in this post. Office 365 offers many robust built-in security features for all customers and also optional controls that enable subscribers to customize their security preferences. More information about security in Office 365 is available in the Office 365 Trust Center.

 

Microsoft Account:

Two-step verification uses two ways to verify your identity whenever you sign in to your Microsoft account:

  • Your password

  • An extra security code

Two-step verification helps protect your account by making it more difficult for a hacker to sign in, even if they’ve somehow learned your password. If you turn on two-step verification, you’ll see an extra page every time you sign in on a device that isn’t trusted. The extra page prompts you to enter a security code to sign in. We can send a new security code to your phone or your alternate email address, or you can obtain one through an authenticator app on your smartphone.

Continue reading

Jan 29 2015

ShmooCon 2015 Presentation Videos

ShmooCon2015 was held in Washington, DC from January 16th -18th, 2015.
The ShmooCon 2015 videos are now posted: https://archive.org/details/shmoocon-2015-videos-playlist

ShmooCon 2015 FireTalks Videos

The complete list of all presentations at ShmooCon 2015 including video download links:

  • Keynote Address: Joseph Lorenzo Hall
    https://archive.org/download/shmoocon-2015-videos-playlist/Keynote%20%5BSC2015%5D.mp4Joseph Lorenzo Hall is the Chief Technologist at the Center for Democracy & Technology, a Washington, DC-based non-profit organization dedicated to ensuring the internet remains open, innovative and free. Hall’s work focuses on the intersection of technology, law, and policy, working carefully to ensure that technology and technical considerations are appropriately embedded into legal and policy instruments. Supporting work across all of CDT’s programmatic areas, Hall provides substantive technical expertise to CDT’s programs, and interfaces externally with CDT supporters, stakeholders, academics, and technologists.

Continue reading

Jan 27 2015

Enabling Windows 8 Hyper-V for a Portable Lab

Installing Hyper-V:

  • Requirement: Windows 8 Pro or Windows 8 Enterprise which include Client Hyper-V.
  • Requirement: Your computer processor must support virtualization technology (VT), though most processors in the past 5 years support VT (pretty much all Intel i-series processors, i3, i5, i7).
  • Enable virtualization technology (VT) on your computer’s processor by editing the BIOS settings at boot-up (many computer BIOS have VT disabled).
  • Open the Start Screen, also referred to as Metro, (press the Windows Key) and search for “Windows Feature”. Open “Turn Windows Features on or off” and scroll down to “Hyper-V”.
  • Expand and Check the box next to Hyper-V. Ensure there is a check box. If there isn’t processor visualization technology, you won’t be able to check the box and enable install of “Hyper-V Platform”.
  • Restart the computer when prompted.

Note: It can take a while for Hyper-V to install – expect it to take 30 – 45 minutes.

 

Jan 23 2015

Shmoocon 2015 FireTalks Videos

The ShmooCon 2015 Presentation Videos are posted.

The ShmooCon Firetalks (2015) are posted:

Videos courtesy of IronGeek.com (Adrian Crenshaw)

Jan 22 2015

Group Policy Settings Reference for Windows 8.1 and Windows Server 2012 R2

 

These spreadsheets list the policy settings for computer and user configurations that are included in the Administrative template files delivered with the Windows operating systems specified. You can configure these policy settings when you edit Group Policy Objects.

The Group Policy Settings reference for Windows & Windows Server can be downloaded here.

Here are the key new Windows 8.1 & Windows Server 2012 R2 Group Policy Settings:
Continue reading

Jan 19 2015

Attackers Can Now Use Mimikatz to Implant Skeleton Key on Domain Controllers & BackDoor Your Active Directory Forest

Once an attacker has gained Domain Admin rights to your Active Directory environment, there are several methods for keeping privileged access. Skeleton Key is an ideal persistence method for the modern attacker. More information on Skeleton Key is in my earlier post.

Note that the behavior documented in this post was observed in a lab environment using the version of Mimikatz shown in the screenshot. There are likely differences in the Skeleton Key malware documented by Dell SecureWorks and the Mimikatz skeleton key functionality. Mimikatz effectively “patches” LSASS to enable use of a master password with any valid domain user. Rebooting the DC refreshes the memory which removes the “patch”.

Implanting the Mimikatz Skeleton Key on one or multiple Domain Controllers:

Mimikatz can now inject a skeleton key into LSASS on the Domain Controller by running the following command on the DC:

mimikatz.exe “privilege::debug” “misc::skeleton” exit

Mimikatz-Skeleton-Implant

When there are multiple Domain Controllers in an Active Directory site, all of them need the Skeleton Key implant to ensure the skeleton key master password is accepted as the user’s valid password.. Since the client discovers a Domain Controller using DCLocator, the DC the client selects is effectively random. If all the DCs don’t have skeleton key configured, the master password won’t work when the client authenticates to a DC without skeleton key.

Scenario:

Continue reading

Jan 16 2015

Active Directory Domain Controller Skeleton Key Malware & Mimikatz

Dell SecureWorks posted about the Skeleton Key malware discovered at a customer site.

The Skeleton Key malware is installed on one or multiple Domain Controllers running a supported 64bit OS.
The malware “patches” the security system enabling a new master password to be accepted for any domain user, including admins.

This enables the attacker to logon as any user they want with the master password (skeleton key) configured in the malware.
“Joe User” logs in using his usual password with no changes to his account.  The attacker can log in as Joe using the skeleton key password and it is seen as a valid logon…

Key Points:

  • Requires domain-level admin rights (and debug rights which admins have by default) to “patch” LSASS on a Domain Controller.
  • All existing user account passwords continue working as normal.
  • Adds a new password that enables the attacker to log on as any user with this password – this is the “skeleton key”.
  • Active Directory Domain Controllers may experience replication issues.
  • User accounts that require a smart card for authentication are not affected.
  • The Skeleton Key malware currently doesn’t remain active after a reboot – rebooting the DCs removes the in-memory patch. Note that DCs are typically only rebooted about once a month.
  • The Skeleton Key malware only works on the following 64-bit systems: Windows Server 2008, Windows Server 2008 R2, and Windows Server 2003 R2.
  • Performs Kerberos encryption downgrade to RC4_HMAC_MD5
  • Mimikatz now has skeleton key functionality and seems to work on all versions of Windows Server…
  • Protect your Active Directory admin accounts and don’t let untrusted code run on Domain Controllers.

Skeleton Key Malware Actions:

Continue reading