If you, for example, administrate your network as the domain admin you are in trouble and nothing will be able to help you.

How design choices made by Microsoft make security hard

From a blog entry about (not)Petya, its impact and how to mitigate similar threats [1]:

authentication was federated to the on premises Active Directory (AD), which was down.

Somebody got their AD DC nuked due to (not)Petya?

Everyone knows it’s hard to secure their network and AD, but that result is …. harsh.

But why is it hard to secure a Windows network with an AD? Especially one that has not been setup by professionals according to the last iterations of Microsoft’s best practices? What is it that most small and many larger companies are missing?

Why is hard to turn a 10+ year old setup into a secure setup?
That turns out to be due to decades old protocols adapted to new uses with disregard to basic security principles.

Defense in depth

To start from the beginning. Having worked with security for a reasonable time the concept off “defense in depth” is one of the few principles that has been a constant [2]. Perhaps “belt and suspenders” is a better term [3]. Wiki defines it as:

Redundant systems, affording mutual backup in the event of one failing.

If one level of your security fails you should not be standing there with your trousers down.
Or your DC unresponsive and dead. Or KRBTGT in the wrong hands.
In other words, you should never trust one security measure to provide a complete protection for your system.
Of course you use authentication, permission sets, MFA, VPN, firewall and antivirus? Would you trust a single of those to protect against everything? Of course not, everyone knows they fail sooner or later. Usually sooner.

Defense in depth usually also has the added bonus of having more points to detect the failure of other layers, aka an intrusion. Therefore defense in depth is important.

It turns out that the depth of defense of an AD infrastructure is shallow. You could hurt your head diving into it. Why?

Networks

One root cause might be that Microsoft never has cared very much about or possibly not understood the network part of security.
I don’t know if it is true, but years ago someone suggested we should use Microsofts best practice for using firewalls.
Suffice to say that they were quite alone at proscribing using two dual homed machines as the entire firewall. That was a long time ago but nothing seems to have become better since then.

The not caring part also applies to some of the network protocols.

Protocols

While doing an investigation around how to segment networks I started with some real-world tools that should be proactively blocked. In the unix world this is usually quite easy.

The first tool I looked at was psexec. Why block RDP, WMI, powershell if you just can use PSEXEC or any of its substitutes to access a server? [4]

To provide defense in depth and not only rely on accounts and permissions we wanted to add another concept: firewalls. In the unix world limiting SSH is a good idea, why not apply the same thinking? That could be host based firewall or a network based. Or why not, ACL in a router. The intention was to stop potential abuse of accounts and limit were users actually can do administrative tasks from.

Blocking RDP and powershell is easy. They run on ports under control of the administrator. If you don’t want them to be accessible: block them. If the block fails due to, for example, the admin relocating them, you have a second protection: permissions. Defense in depth – if one fails you have a second, or third, or… something protection.

Of course, if you have for example a webserver, life is easy, open 80 (of course just a redirect to 443 😉 ) and 443 – end of story. But lots of windows servers require other protocols such as SMB.

An added complexity is that per system rules are nice… if you did if from the beginning. Applying them after the fact on a large server farm? Worst job ever. If you as an admin know every system inside and out? Why not. If you need to look up each host name in the inventory to be able to track down the owner…

Back to SMB. It turns out that if you need to have SMB open to any server you cannot stop PSEXEC.

PSEXEC requires three things:

1) Administrative permissions on the target system
2) SMB access to the target system
3) Access to RPC on the target system

It turns out that RPC travels nicely over named pipes over SMB… [5]
So 2 and 3 are the same. And to provide defense in depth we wanted to add something to 1…

Unless you have a firewall with very deep inspection you cannot actually add anything in-between that will block creation of any remote tool working in the same manner as PSEXEC. And blocking SMB will break a long list of things you wouldn’t expect break from blocking what most think is a file sharing protocol [6].

RPC

Back to the drawing board figuring out how to segment something more important than the average file server. Let’s go big, go AD.

Firstly there was the problem with SMB…Ignoring that and instead looking at other features commonly used by attackers we looked  at blocking features such as DCSYNC [7].

MS-DRSR/DRSUAPI is a RPC protocol used to syncronize data between domain controllers [8]. Without having done a deeper analysis that looked like a prime example of an RPC service that should have no legitimate use outside of the DC infrastructure. So go ahead, lets block client computers from calling it.

Unfortunately the RPC API supplies more functions,  including ones that are used by applications.For example DsCrackNames can sometimes be seen [9].

So, bad luck for blocking a service that never ever should be accessible from outside of the small network of domain controllers!

Oddities

Slightly off topic, but while looking at a PCAP from one of my own machines I notices something odd. A domain joined machine were the domain policy for kerberos lifetime was 10 hours was requesting tickets valid until 2037… No, I had not played around with mimikatz.
Kerberos lifetime seems to be set by GPO. If, for one reason or another the node does care for the GPO it just takes the maximum lifetime.
Using a “client must be compliant” approach to such security functions is bound to cause trouble sooner or later.

Segmentation

It might be that Microsoft themselves have noticed some of these issues. Why else produce a product that helps detecting these and other attacks [10]?

The end result is that the only effective protection is total control over high value accounts. The recommendations are very clear in Microsofts best practices and other communication.

If a threat actor has acquired the credentials needed for lateral traversal, you can NOT block the attack by disabling execution methods like PowerShell or WMI. [1]

You cannot effectively separate high value AD servers from low value systems using network segmentation. AD requires allowing traffic inherently dangerous. The gist of Microsofts best practices is to limit exposure of high value accounts to systems that are tightly controlled and therefore less likely to be compromised. This, given the protocol design, is most likely the only effective protection.

If you fail protecting the high value accounts there will be no second level of defense – it’s game over. You cannot block someone who has got hold of the wrong credentials from breaking your system.

To make matters worse, detection is not easy either. It would be easy if attack traffic would be anomalies, but it isn’t. Mimikatz abuses protocol features within the limitations of those features because it does not need to go outside of those limitations.

Had a number of small engineering decisions along the line been different, we would see far less compromised, or wiped for that matter, AD domains. A small number of design changes making it possible to remove access to intra-DC protocols and any protocol that can be used to remotely execute code would have made it possible build a forgiving environments that accepts the occasional fail.

The wishlist is not long:

• Making RPC over SMB optional and possible to disable
• Use default ports for all services giving remote access (serversvc, WinRM/PS, WMI, task scheduler etc)
• Separate intra-DC services from client services and put on a default port

Guest article by @rndHashValue 2018

[1] https://cloudblogs.microsoft.com/microsoftsecure/2018/02/05/overview-of-petya-a-rapid-cyberattack/
[2] https://en.wikipedia.org/wiki/Defense_in_depth_(computing)
[3] https://en.wiktionary.org/wiki/belt_and_suspenders
[4] https://securelist.com/olympicdestroyer-is-here-to-trick-the-industry/84295/
[5] https://blog.skullsecurity.org/2008/calling-rpc-functions-over-smb
[6] https://support.microsoft.com/en-us/help/3185535/guidelines-for-blocking-specific-firewall-ports-to-prevent-smb-traffic
[7] https://adsecurity.org/?p=1729
[8] https://wiki.samba.org/index.php/DRSUAPI and https://msdn.microsoft.com/en-us/library/cc228532.aspx
[9] https://msdn.microsoft.com/en-us/library/ms675970(v=vs.85).aspx
[10] https://www.microsoft.com/en-us/cloud-platform/advanced-threat-analytics