So You Think Your Domain Controller Is Secure?

1. So You Think Your Domain Controller Is Secure? Justin Hendricks Security Engineer Twitter - @Script_happens

2. Introduction • Presentation covers basic domain controller isolation principles. • Recommendations for securely configuring software used to manage domain controllers (SCOM, HP iLO, and Hyper-V). • No vulnerabilities are discussed. • Only demonstrations on how features could be abused if not configured properly.

3. Background • Domain Controllers • Handle authentication of domain accounts in Windows. • Stores password hashes for all domain accounts. • The crown jewels of the domain. • Recommendations for securing domains focus on pass-the-hash and account segmentation • Software used to manage DCs is often overlooked.

4. Background • System Center Operations Manager (SCOM) • Software used to monitor server health. • Great SCOM security guide available: • http://technet.microsoft.com/library/bb821997.aspx • Out-Of-Band Management Devices • Used to monitor and manage servers over the network regardless of the server state. • Guidance on securing OOB devices: • http://www.sans.org/reading_room/whitepapers/networkdevs/securing-out-of-band-device-management_906

5. Background • Hyper-V • Windows Server Virtualization Software • Running domain controllers in Hyper-V: • http://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(v=ws.10).aspx • “The host computer on which virtual domain controllers are running must be managed as carefully as a writeable domain controller…”

6. Monitoring Software • System Center Operations Manager (SCOM) is used for monitoring and alerting of server health. • SCOM management server hosts the SCOM SDK service on port 5723 and 5724. • Required to be open in order to pull data across environment boundaries. Firewalls often configured to allow these ports. • Default NMap scan does not check these ports. • SCOM agent which runs on monitored servers typically runs as SYSTEM.

7. Abusing Functionality • SCOM “tasks” allow you to run VBScript on monitored servers. • Any account in the SCOM ‘Administrators’ or ‘Authors’ roles can run VBScript on any monitored server. • Code runs under the SCOM agent which is configured to run as SYSTEM by default. • SCOM servers that monitor domain controllers should be treated as domain controllers.

8. SCOM SDK Architecture

9. Default SCOM Agent Credentials

10. Security Warnings • Many existing articles warn users of the dangers of running tasks under high-privileged accounts: • http://www.code4ward.net/main/Blog/tabid/70/EntryId/83/Invoke-External-Programs-and-Scripts-in-SCOM-Tasks.aspx • “In this example we will create very generic agent task. You can use this task to execute any command on any windows computer. Be careful with the distribution of this task as it is very dangerous but also very powerful!“ • http://technet.microsoft.com/en-us/library/bb735423.aspx • “The default account for the Run As profile is the action account. Give appropriate thought to what the action account should be and choose an account with appropriate permissions. In most instances, a domain administrator would not be a good choice.” • http://blogs.technet.com/b/kevinholman/archive/2012/02/17/security-in-operations-manager-some-perspectives-and-typical-customer-scenarios.aspx • “In this way – you should take care of what tasks to allow operators to be able to run – the default behavior is possible elevation of their privileges… to be able to execute a task running under a pre-defined credential such as local system, or a SQL run-As account.”

11. Demo • Creating SCOM tasks to run arbitrary code.

12. Recommendations • Segregate SCOM servers used to monitor domain controllers. • Close off SCOM SDK ports (5723 and 5724). • Reduce SCOM ‘Administrators’ and ‘Authors’ roles to only domain admins. • Move support and engineers to ‘Read-Only’ or ‘Operator’ SCOM roles. • Reduce SCOM agent privileges. • Follow the official SCOM security guide: • http://technet.microsoft.com/library/bb821997.aspx

13. Detection and Evasion • SCOM tasks should be audited to detect hidden malicious tasks. • SCOM stores task execution logs in the SCOM database. • Default retention is 7 days, but can be changed. • SCOM SDK connections logged in “Operations Manager” event log.

14. SCOM Task History

15. Out-Of-Band Management Devices • Servers usually have OOB management hardware used for server monitoring and maintenance. • HP Integrated Lights Out (iLO), Dell DRAC, IBM Integrated Management Module (IMM), etc • Equivalent to physical access to a server. • Admin interface accessed over HTTP/HTTPS, SSH, IPMI. • Commonly have default passwords set. • Remote Root Vulnerabilities: • https://community.rapid7.com/community/metasploit/blog/2013/06/23/a-penetration-testers-guide-to-ipmi • Difficult to patch.

16. HP ILO Security Override Switch

17. OOB Device Default Passwords

18. Demo • Using HP iLO to mount Linux live disc.

19. Recommendations • Change default passwords. • Have regular patching process for OOB devices. • Monitor audit logs for unauthorized access. • Configure 2FA when possible • Set up separate management VLAN for OOB devices. • SANS paper on securing OOB devices: • http://www.sans.org/reading_room/whitepapers/networkdevs/securing-out-of-band-device-management_906

20. Hyper-V • Windows virtualization software that hosts virtual machines. • Administrator on the host is equivalent to admin rights on all guest virtual machines. • Can boot into a Linux live disc or steal the VHD file to compromise domain controller VM.

21. Booting Into Linux Live Disc

22. Stealing NTDS.DIT and SYSTEM hive

23. Recommendations • Segregate Hyper-V servers that host domain controllers. • Only domain admins should have access to: • Hyper-V servers hosting domain controllers. • Domain controller VHDs. • Host should be in a separate management network when possible. • Additional guidance: • http://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(v=ws.10).aspx

24. Vulnerability Scanners • Organizations typically perform authenticated vulnerability scanning. • The account used is typically very high privileged and has admin access to domain controllers. • These servers should be treated as a domain controller if they use domain admin credentials.

25. Conclusion • Management software and hardware is often highly privileged and can be abused if not properly secured. • Segregate management of domain controllers from other categories of servers.

26. Contact Info • Twitter - @Script_Happens • Presentation Content will be posted on: https://scripthappens.azurewebsites.net/