May 07 2015

Windows 10 Microsoft Passport (aka Microsoft Next Generation Credential) In Detail

At the Microsoft Ignite conference this week, there are several sessions covering Windows 10 features. One of biggest changes in Windows 10 is the new credential management method and the related “Next Generation Credential”, now named Microsoft Passport.

There hasn’t been much information on how the new credential system works, so I challenged myself to gather as much information and understand it as best as possible before the Microsoft Ignite conference ends this week. This post covers my understanding of this (still beta) technology.

Note that the information in this post is subject to change (& my misunderstanding). As I gain clarification, I will update this post.

1/28/2016 Update: Microsoft published a whitepaper on Microsoft Passport and Windows Hello. This post will soon incorporate this information.

Microsoft Passport

Microsoft has resurrected the Passport moniker for a new PKI credential system that requires multi-factor authentication.Most interesting about Microsoft Passport is that it fully supports the Fast IDentity Online (FIDO) Alliance standards which means it will work with many web/cloud services without modification. The plan is that users of cloud services supporting FIDO is that there will no longer be passwords associated with the user’s account.

Microsoft Passport involves a user logging onto the Windows 10 computer with multi-factor (PIN, face, iris, fingerprint, etc) and either creating a new account or associating an existing account with an IDentity Provider (IDP). Windows generates a public/private key pair with the private key stored securely outside of the Windows 10 OS. The public key is associated with the account so that a challenge can be sent that can only correctly respond to the IDP. Another key point to the Microsoft Passport credential system is that the user needs to enroll every device used to access the service (IDP).

Continue reading

May 06 2015

Windows Server 2016 Technical Preview 2 Now Available for Download

Windows Server 2016 Technical Preview 2 Now Available for Download (ISO or VHD):
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

What’s new in Active Directory Domain Services (AD DS) in Windows Server Technical Preview:

Privileged access management

Privileged access management (PAM) helps mitigate security concerns for Active Directory environments that are caused by credential theft techniques such pass-the-hash, spear phishing, and similar types of attacks. It provides a new administrative access solution that is configured by using Microsoft Identity Manager (MIM). PAM introduces:

  • A new bastion Active Directory forest, which is provisioned by MIM. The bastion forest has a special PAM trust with an existing forest. It provides a new Active Directory environment that is known to be free of any malicious activity, and isolation from an existing forest for the use of privileged accounts.
  • New processes in MIM to request administrative privileges, along with new workflows based on the approval of requests.
  • New shadow security principals (groups) that are provisioned in the bastion forest by MIM in response to administrative privilege requests. The shadow security principals have an attribute that references the SID of an administrative group in an existing forest. This allows the shadow group to access resources in an existing forest without changing any access control lists (ACLs).
  • An expiring links feature, which enables time-bound membership in a shadow group. A user can be added to the group for just enough time required to perform an administrative task. The time-bound membership is expressed by a time-to-live (TTL) value that is propagated to a Kerberos ticket lifetime.
    noteNote
    Expiring links are available on all linked attributes. But the member/memberOf linked attribute relationship between a group and a user is the only example where a complete solution such as PAM is preconfigured to use the expiring links feature.
  • KDC enhancements are built in to Active Directory domain controllers to restrict Kerberos ticket lifetime to the lowest possible time-to-live (TTL) value in cases where a user has multiple time-bound memberships in administrative groups. For example, if you are added to a time-bound group A, then when you log on, the Kerberos ticket-granting ticket (TGT) lifetime is equal to the time you have remaining in group A. If you are also a member of another time-bound group B, which has a lower TTL than group A, then the TGT lifetime is equal to the time you have remaining in group B.
  • New monitoring capabilities to help you easily identify who requested access, what access was granted, and what activities were performed.

Requirements

  • Microsoft Identity Manager
  • Active Directory forest functional level of Windows Server 2012 R2 or higher.

Azure AD Join

Azure Active Directory Join enhances identity experiences for enterprise, business and EDU customers- with improved capabilities for corporate and personal devices.

Benefits:

  • Availability of Modern Settings on corp-owned Windows devices. Oxygen Services no longer require a personal Microsoft account: they now run off users’ existing work accounts to ensure compliance. Oxygen Services will work on PCs that are joined to an on-premises Windows domain, and PCs and devices that are “joined” to your Azure AD tenant (“cloud domain”). These settings include:
    • Roaming or personalization, accessibility settings and credentials
    • Backup and Restore
    • Access to the Windows Store with work account
    • Live Tiles and notifications
  • Access organizational resources on mobile devices (phones, phablets) that can’t be joined to a Windows Domain, whether they are corp-owned or BYOD
  • Single-Sign On to Office 365 and other organizational apps, websites and resources.
  • On BYOD devices, add a work account (from an on-premises domain or Azure AD) to a personally-owned device and enjoy SSO to work resources, via apps and on the web, in a way that helps ensure compliance with new capabilities such as Conditional Account Control and Device Health attestation.
  • MDM integration lets you auto-enroll devices to your MDM (Intune or third-party)
  • Set up “kiosk” mode and shared devices for multiple users in your organization
  • Developer experience lets you build apps that cater to both enterprise and personal contexts with a shared programing stack.
  • Imaging option lets you choose between imaging and allowing your users to configure corp-owned devices directly during the first-run experience.

For more information see, Extending Modern Experiences and Single Sign On across Company Apps on Windows with Azure Active Directory Join.

Microsoft Passport

Microsoft Passport is a new key-based authentication approach organizations and consumers, that goes beyond passwords. This form of authentication relies on breach, theft, and phish-resistant credentials.

The user logs on to the device with a biometric or PIN log on information that is linked to a certificate or an asymmetrical key pair. The Identity Providers (IDPs) validate the user by mapping the public key of the user to IDLocker and provides log on information through One Time Password (OTP), Phonefactor or a different notification mechanism.

For more information see, Password-less Authentication with Microsoft Passport

Deprecation of File Replication Service (FRS) and Windows Server 2003 functional levels

Although File Replication Service (FRS) and the Windows Server 2003 functional levels were deprecated in previous versions of Windows Server, it bears repeating that the Windows Server 2003 operating system is no longer supported. As a result, any domain controller that runs Windows Server 2003 should be removed from the domain. The domain and forest functional level should be raised to at least Windows Server 2008 to prevent a domain controller that runs an earlier version of Windows Server from being added to the environment.

At the Windows Server 2008 and higher domain functional levels, Distributed File Service (DFS) Replication is used to replicate SYSVOL folder contents between domain controllers. If you create a new domain at the Windows Server 2008 domain functional level or higher, DFS Replication is automatically used to replicate SYSVOL. If you created the domain at a lower functional level, you will need to migrate from using FRS to DFS replication for SYSVOL. For migration steps, you can either follow the procedures on TechNet or you can refer to the streamlined set of steps on the Storage Team File Cabinet blog.

The Windows Server 2003 domain and forest functional levels continue to be supported, but organizations should raise the functional level to Windows Server 2008 (or higher if possible) to ensure SYSVOL replication compatibility and support in the future. In addition, there are many other benefits and features available at the higher functional levels higher. See the following resources for more information:

Continue reading

May 03 2015

Detecting Forged Kerberos Ticket (Golden Ticket & Silver Ticket) Use in Active Directory

Over the last 6 months, I have been researching forged Kerberos tickets, specifically Golden Tickets, Silver Tickets, and TGTs generated by MS14-068 exploit code (a type of Golden Ticket). I generated forged Kerberos tickets using Mimikatz (Mimikatz Command Reference) and MS14-068 exploits and logged the results. Over the course of several weeks, I identified anomalies in the event logs that are clear indication of forged ticket use in an Active Directory environment.

Update1/5/2016:
Around this time last year (early January 2015), I shared with customers these indicators for detecting forged Kerberos tickets and subsequently presented this information at BSides Charm 2015. Soon after, Mimikatz was updated with a domain field that was set to static values, usually containing the string “eo.oe”. As of the Mimikatz update dated 1/5/2016, forged Kerberos tickets no longer include a domain anomaly since the netbios domain name is placed in the domain component of the Kerberos ticket.

Mimikatz code diff:
GT-DomainFieldUpdate-20150105

More information on the difficulty of detecting forged Kerberos tickets (Golden Tickets, Silver Tickets, etc) in the in the Detecting Forged Kerberos Tickets section below.

 

Kerberos Overview & Communication Process:

Visio-KerberosComms

User logs on with username & password.

1a. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an authenticator in the authentication ticket (TGT) request (AS-REQ).
1b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) & creates Ticket-Granting Ticket (TGT).

2. The TGT is encrypted, signed, & delivered to the user (AS-REP). Only the Kerberos service (KRBTGT) in the domain can open and read TGT data.

3. The User presents the TGT to the DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check out, TGT = valid. The data in the TGT is effectively copied to create the TGS ticket.

4. The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP).

5.The user connects to the server hosting the service on the appropriate port & presents the TGS (AP-REQ). The service opens the TGS ticket using its NTLM password hash.

6. If mutual authentication is required by the client (think MS15-011: the Group Policy patch from February that added UNC hardening).

Unless PAC validation is required (rare), the service accepts all data in the TGS ticket with no communication to the DC.

 

Active Directory Kerberos Key Points:

  • Microsoft uses the NTLM password hash for Kerberos RC4 encryption.
  • Kerberos policy is only checked when the TGT is created & the TGT is the user authenticator to the DC.
  • The DC only checks the user account after the TGT is 20 minutes old to verify the account is valid or enabled. TGS PAC Validation only occurs in specific circumstances. When it does, LSASS on the server sends the PAC Validation request to the DC’s netlogon service (using NRPC)
  • If it runs as a service, PAC validation is optional (disabled). If a service runs as System, it performs server signature verification on the PAC (computer account long-term key).

 

Forging Kerberos Tickets:

  • Forging Kerberos tickets depends on the password hash available to the attacker
  • Golden Ticket requires the KRBTGT password hash.
  • Silver ticket requires the Service Account (either the computer account or user account) password hash.
  • Create anywhere and user anywhere on the network, without elevated rights.
  • Spoof access without modifying AD groups.
  • Once the KRBTGT account password is disclosed, the only way to prevent Golden Tickets is to change the KRBTGT password twice, since the current and previous passwords are kept for this account.

 

Golden Tickets:

Continue reading

Apr 12 2015

SPN Scanning – Service Discovery without Network Port Scanning

The best way to discover services in an Active Directory environment is through what I call “SPN Scanning.”

The primary benefit of SPN scanning for an attacker over network port scanning is that SPN scanning doesn’t require connections to every IP on the network to check service ports. SPN scanning performs service discovery via LDAP queries to a Domain Controller. Since SPN queries are part of normal Kerberos ticket behavior, it is difficult, if not infeasible to detect, while netowkr port scanning is pretty obvious.

Service Principal Names (SPNs) are required for discovery of services that leverage Kerberos authentication.

Continue reading

Mar 22 2015

Bypassing EMET 5.2 Security Protection

While EMET 5.2 may only be about a week old, there is already information about one way tor bypassing one of EMET’s security protection methods.

r41p41 posted information about ROP bypass in the latest EMET version, 5.2.

TLDR: EMET 5.2 can be bypassed with ease by jumping past its hooks using simple ROP
19th March 2015 Addition: I’ve bypassed EMET’s protections with generic ROP too, no need to specifically target now. However i am not releasing the POC.

Only effective bypass up until now for EMET was the one which offensive security guys did.
offsec EMET 5.1

 

I was trying the same approach before, but since the arrival of EMET 5.2 it was only a matter of time before someone reverse engineered EMET’s internal structures and found out a bypass. My time was both limited and valuable, So i jumped right into it. Upon watching ollydbg’s memory mapping, i saw TONS of page guards in memory.
Something told me this approach would only end in sophistication.
and i changed my approach thus manually began browsing EMET’s hook handler.

 

Conclusion

EMET fights tough, more than any public exploit mitigation solution out there. A lot tougher than MBAE and enterprise exploit detection products.
But if we get to study the system, its only a matter of time.
Addition: On March 19th 2015, i managed to bypass EMET’s protections using GENERIC rop. So even if emet exists or not in the system the exploit works fully. However due to its more negative use than positive, i am not releasing the code. Icing on the top, this bypasses all of the enterprise exploit mitigation toolkits i’ve got my hands on. A small explanation is blogged here.

Read more on Defeating EMET 5.2
(Note: There is language some may find offensive.)

 

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