23
Securing Your Data in an Open World Developing a Secure Active Directory

Developing a Secure Active Directory

Embed Size (px)

Citation preview

Page 1: Developing a Secure Active Directory

Securing Your Data in an Open World

Developing a Secure Active Directory

Page 2: Developing a Secure Active Directory

INTRODUCTION

Page 3: Developing a Secure Active Directory

Agenda

Risks

Mitigations

Validation and Auditing

Tips from the Field

Page 4: Developing a Secure Active Directory

PASS THE HASH

Convenience of SSO at cost of additional risk.

What makes a “hash” in this context?

h = 𝑓(𝑥)

Predates Windows NT 3.1 but still very much applicable today.

A stolen hash creates the potential for impersonation.

A stolen hash inherits any authorizations granted to the account.

Page 5: Developing a Secure Active Directory

PASS THE HASHBASIC SCENARIO

Bob logs on to CORP\BOB-E550.

Windows SAM stores his hash in kernel memory.

Alice logs on remotely to BOB-E550.

Alice is a member of BUILTIN\Administrators.

Alice performs a memory dump of BOB-E550 from an elevatedprocess.

Alice exfiltrates the memory dump to her workstation using SMB.

Alice extracts Bob’s hash from the memory dump offline.

Page 6: Developing a Secure Active Directory

PASS THE HASHBASIC LESSONS

Limiting opportunities for untrusted processes to elevate is important.

User Access Control (UAC) is a first line of defense.

What if Bob was a Domain Admin?

If Alice has local admin, do you trust Alice enough to see everything in RAM on that

system.

If we can’t protect a user’s identity, the concept of identity or authentication on our

network is weakened.

Page 7: Developing a Secure Active Directory

PASS THE HASHCROSS-SYSTEM

PC-A and PC-B both have a local user named “helpdeskadmin”

The plaintext password for .\helpdeskadmin is Tr1viAl&triNg.

The equivalent hash for the account is the same on both machines.

A compromise of the hash by a process on PC-A can be used to attack any other

Windows host that has that same username and password combination, even without

knowledge of the plaintext password.

Page 8: Developing a Secure Active Directory

PASS THE HASHCROSS-SYSTEM LESSONS

Again, process elevation creates the opportunity.

Diversification of local user passwords across machines is important.

See MS KB3062591: Local Administrator Password Solution (LAPS)

Bewareprevious solutions; not all similar solutions use secure communications for

storing the local admin password.

Restrict remote logon of local accounts where it isn’t needed.

Page 9: Developing a Secure Active Directory

PASS THE HASHRECENT DEVELOPMENTS

Windows 10/Server 2016 introduces Isolated User Mode.

Store NTLM hashes in a virtualized micro-kernel.

Hypervisor executing the micro-kernel acts as a gatekeeper.

Limited implementation details available.

Concerns of how much protection this really provides.

Ultimately, will need to be audited and tested before we know.

Page 10: Developing a Secure Active Directory

LANMAN and NTLM

For compatibility, AD can still communicate using LM or NTLM.

Both have known and easy to exploit weaknesses.

Allowing older protocols creates opportunity for downgrade attacks.

Similar to SSL/TLS downgrade attacks popular in 2014.

Group Policy can be used to restrict or eliminate use of NTLM.

Page 11: Developing a Secure Active Directory

LMv1 and NTLMv1

Source: SANS Digital Forensicshttp://bit.ly/1JXjuuG

Page 12: Developing a Secure Active Directory

PRIVILEGED GROUPS AND USERSBEST PRACTICES

Disable BUILTIN\Administrator.

Disable network logon for the local administrator account .

Do not perform day-to-day activities as with your admin account.

Do not keep users in Enterprise or Schema Admins.

Do not log on to client systems with privileged network accounts.

Don’t disable password expiration on privileged accounts.

Don’t use Domain Admin as a shortcut for domain-wide needs.

Page 13: Developing a Secure Active Directory

KERBEROS

Provides enhanced authentication architecture and cryptography.

Not a Pass-the-Hash mitigation; see Pass-the-Ticket.

Keeping your entire Windows environment patched is key to maintaining a secure

Kerberos environment.

Vectors exist where Kerberos tickets are forged; See MS14-068.

Kerberos, like any many protocols, requires iteration to improve its security and so

we mustpatch.

Page 14: Developing a Secure Active Directory

Source: SANS Digital Forensicshttp://bit.ly/1JXjuuG

Page 15: Developing a Secure Active Directory

ENTERPRISE CA

Why run an Enterprise CA?

For existing Windows CAs, implications of SHA-1 deprecation.

http://bit.ly/mscasha1to2

A Windows CA is not fire-and-forget; it needs maintenance, too.

Page 16: Developing a Secure Active Directory

ANONYMOUS BINDS & ENUM

Enabled on many domains upgraded from NT/Server 2000.

Anonymous bind off by default in Server 2003 and later for new domains.

Easy intelligence source for hostile actors.

For binds, modify dsHeuristics object in an editor like ADSI.

For enumeration, a Group Policy setting exists.

Can impact pre-2000 clients and domain trust functionality.

Need to understand what relies on anonymous access today.

May not be feasible to disable; part of the hardening process.

Page 17: Developing a Secure Active Directory

MONITORING

When active defense fails, a passive approach can help.

Changes to privileged groups (integrity monitoring).

Invalid attributes in Kerberos requests.

Presence of NTLM authevents Security log.

Statistical anomalies (Fail Audit volume, request volume, lockouts).

Security Information and Event Management products exist for this.

AD / NTFS Auditing is extremely valuable if configured well.

Page 18: Developing a Secure Active Directory

READ-ONLY DCs

Many associate RODCs with branch offices or poor connectivity.

An option for providing LDAP data in potentially hostile or untrusted environments:

Low physical security.

Multi-tenant environments.

Can restrict the replication of password hashes to RODCs.

Why? Offline attacks after physical loss.

By the same token, must physically secure writeable DCs’ disks and their backups.

Page 19: Developing a Secure Active Directory

DATA PROTECTION

Not an active protection, but like any data, a backup is equally critical.

While not exactly a security topic, it is often overlooked.

It’s not enough to snapshot your virtual DCs.

In fact, it’s dangerous if the DC is anything older than 2012 R2.

A Windows System State backup of any DC will back up the AD database.

Several agent-based backup products can capture the system state.

Page 20: Developing a Secure Active Directory

AUDIT AND VALIDATION

All of these measures are helpful, but less meaningful without validation.

Third party firms.

Microsoft Consulting opportunities.

SaaS vulnerability scanning services.

In-house testing (MBSA).

Page 21: Developing a Secure Active Directory

OTHER TIPS

Enforce CTRL+ALT+DEL as the secure keystroke on clients.

Avoid using web browsers on servers.

Inspect software thoroughly before executing on a server.

Don’t disable the Windows Firewall.

Don’t disable UAC on any Windows systems if it can be avoided.

Page 22: Developing a Secure Active Directory

STAY INFORMED

Attend security sessions at conferences (MS Ignite, VMworld, etc).

Engage with an IT security provider where it makes sense for you.

Monitor consistent, well-maintained sources:

US-CERT (us-cert.gov)

SANS ISC (isc.sans.edu) and Threat Level status.

Microsoft Technical Security Notifications (http://bit.ly/mssecnot)

Talk about security within your organizations.

Page 23: Developing a Secure Active Directory

Thank You