IT not doing enough to secure Active Directory, says expert

It’s long been known that members of IT teams often don’t speak to each other. Just as data can be siloed, so can people.

Sean Metcalf, one of only 100 or so Microsoft Certified Masters for Active Directory, made the discovery in 2014 after going to security conferences and asking penetration testers and red teamers just how successful they are at getting access to administration rights and “crown jewels.”

This happens almost 99 per cent of the time, they said. But when Active Directory administrators were questioned, they said it would be impossible for attackers to beat them.

“We have a problem because there’s a huge gap between what the security industry has been doing and what the security and network folks have been doing,” Metcalf said in an interview.

“We need to pull that together. We need to have a better understanding of how security works in an enterprise, which ultimately comes down to security for Active Directory.”

One problem is the Windows/Microsoft team often looks after AD, not the security team.

“There should be some input between the systems folks and the security folks,” he said. Unfortunately, he added, often AD administrators only worry about compliance: “These are the security settings we require. Okay we’ve deployed these security settings.”

Whether these settings improve security is debatable, Metcalf notes, adding the real question should be around what are attackers doing and what are the settings inhibiting attackers?

“In my experience the answer is no.”

Today Metcalf is chief technology officer for DAn Solutions Inc., an Arlington, Va.-based consulting company, who helps organizations overhaul their Active Directory systems.

He’s also behind the Active Directory Security blog, where he shares information about threats to enterprise networks  as well as AD  design and configuration tips.

Sean Metcalf: How to fix common Active Directory security issues

If CISOs want to secure an organization, he says, the place to start is AD.  According to Forrester Research, because it comes free with Windows Server, Active Directory is the most widely used enterprise repository for digital identities.

That also means it’s a tempting target for hackers to elevate privileges and pilfer data. Their strategy is simple: Gain a toehold in a desktop or server, search laterally through the network to find the valuable data, escalate privileges to gain administration rights, use those rights to steal and get away with it.

“I see Active Directory basically as the enterprise,” says Metcalf. “because it is like the network registry for all the systems. It provides authentication, it provides security, it provides management — it provides all these features, and you get it when you purchase Windows Server.”

Like any piece of software, AD has vulnerabilities, but Metcalf doesn’t believe it’s inherently insecure. With the latest and patched versions of Windows Server — Metcalfe believes Windows Server 2003 should be banned — and at least Windows 7 on desktops, it’s pretty safe. And patching is vital: He still sees customers that haven’t installed a major fix for domain controllers that was issued in November of 2014: “That one vulnerability could lead to a full Active Directory compromise,” he said.

However, he adds, often attackers exploit AD holes that have been there for years, such as not configuring the network to use the NTLM v.2 authentication protocol. Instead — sometimes because of third party compatibility — NTLM v.1 is still in use.

There are two other problems which could be described as sloppy policies and wobbly deployment.

Usually the IT department sets an AD design, deploys it, and over the years it becomes skewed from the original configuration as accounts are added and deleted, rights are pulled back, or additional components are included; eventually an update is needed to match business requirements.

That modernization will include overhauling and limiting the rights of AD administrators, Metcalfe says. As many infosec pros have said, the fewer people who have admin rights, the better.

Metcalf goes further, urging CISOs to do away with creating domain admins. Instead, create custom delegation groups and give them only the rights they need. In addition, set up a system of temporary admin rights: When someone needs them, they have to get permission.

“We need to set up more barriers for attackers which enable us to better detect and mitigate the attacks,” he said. “Unfortunately, the side effect to this is these barriers make things harder for the admins….This happens because many attackers are using valid admin tools to persist and escalate access in the network.”

For those administrators who remain, it’s vital to ensure they follow safe password practices, including changing passwords regularly and only using their admin passwords on systems that aren’t connected to the Internet.

On top of that, the password to the KRBTGT Active Directory account — where Kerebos authentication tickets are stored — should be changed twice a year.

Steps should be taken to ensure administrators of local groups randomize their admin account passwords and are managed with Microsoft’s Local Administrator Password Solution (LAPS) or TrustedSec’s Shared Host Integrated Password System (SHIPS).

Another important policy is to document everything that’s done; it’s often difficult for administrators to figure out who has what rights. “I found a server admin group that is ultimately nested under a group that gives full rights to Active Directory and all the components in it. That’s another case of ‘over permissioning’ — someone had just added that group to another group that had rights they didn’t understand the full implications.”

Along side documentation comes logging. “Defence starts with logs,” Metcalf once told a conference. PowerShell, Microsoft’s [Nasdaq: MSFT] scripting environment, is for task automation and management. It’s also a prime vector for attacks through PowerSploit and the new PowerShell Empire exploit kits. To protect against that, Windows needs to be configured to log and manage all PowerShell activity. In addition, PowerShell  remote access can be limited to loading by specific administrator subnets.

PowerShell v5 — which has been briefly pulled to fix a bug — includes security enhancements for script block logging, system wide transcripts and a constrained mode to help stop attacks. Note that Windows 10 won’t run PowerShell code until it has been scanned by antivirus/anti-malware on a system, one advantage to moving to the operating system. User behavior tools (such as Microsoft’s new Advanced Threat Analytics) can look at traffic going to and from domain controllers to identify suspicious traffic.

Finally, Metcalf makes a non-AD but security-related plea: No more flat networks.  That means no network connected device — including workstations, printers, and appliance — should have direct access to any critical servers. Those systems have to be isolated and protected either through a host-based firewall or through a network configuration on the network devices.

Remember, Metcalf one told a conference, during the disastrous Target breach in 2014, investigators discovered that a scale in the meat department of one store could access a point of sale (POS) device in another.