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

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.

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.

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

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_hy perv(v=ws.10).aspx “The host computer on which virtual domain controllers are running must be managed as carefully as a writeable domain controller…”

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.

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.

SCOM SDK Architecture

Default SCOM Agent Credentials

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.”

Demo Creating SCOM tasks to run arbitrary code.

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

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.

SCOM Task History

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.

HP ILO Security Override Switch

OOB Device Default Passwords Default Username Default Password Dell Remote Access Card (DRAC) root Calvin IBM Integrated Management Module (IMM) USERID PASSW0RD HP Integrated Lights Out (iLO) Administrator <Random 8 char string> Fujitsu Integrated Remote Management Controller admin Supermicro IPMI (2.0) ADMIN Oracle/Sun Integrated Lights Out Manager (ILOM) Changeme ASUS iKVM BMC

Demo Using HP iLO to mount Linux live disc.

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

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.

Booting Into Linux Live Disc

Stealing NTDS.DIT and SYSTEM hive

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_virtualiza tion_hyperv(v=ws.10).aspx

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.

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.

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