Like a US drug commercial...
What are the side effects?
An infosec firm has unleashed a NotPetya-style worm onto a customer’s network – and discovered that a simple Windows Active Directory tweak has a surprising effect on self-spreading malware. In the wake of the outbreak of NotPetya – so-called because it masquerades as Petya ransomware – one of NCC Group's customers asked the …
It's set on Domain Admin accounts by default. And members of BUILTIN\Administrators and similar groups. You don't want to set it on normal user accounts, because the only way you can manage accounts with the Admin flag set would be by another account that has Domain Admin privileges.
So that would screw up your account management delegations (since you don't want Domain Admins doing general account operations except in your crappy AD lab).
The best thing by far is to fix up your AD security - don't use the built-in Server Operators and Account Operators groups, and check very carefully how you delegate OU permissions. i.e. don't give your account operations team Full Control to all your user OUs - ensure you're selecting user objects only. And stop logging on with Domain Admin accounts everywhere. Those accounts should only be logging onto DCs, and not directly from your workstations, and only for actual domain-level changes.
I think you've misunderstood.
Delegation in the context of "Account is sensitive and cannot be delegated" is *Kerberos* delegation - not delegation of control in AD DS, which is just adding permissions to an ACL much like granting rights over files and folders.
To be clear, enabling this setting doesn't impact delegation of administration in AD DS.
Kerberos delegation allows a user/computer/service to act on behalf of another user, and can be unconstrained Kerberos delegation, or constrained to specific services using Kerberos (i.e. Kerberos Constrained Delegation - KCD) or any authentication protocol (e.g. for NTLM protocol transition). The less constrained, the higher the risk (in theory). ISA/TMG reverse proxying and SharePoint are/were common use cases for this functionality.
There's some great new functionality for Protected Accounts available in AD DS and the OS from Windows Server 2012 R2 and Windows 8.1 and above that offers significant protection in this space, but requires configuration - it's not on by default. Protected Accounts, in a domain with functional level Windows Server 2012 R2 or higher, cannot 'be delegated by using unconstrained or constrained delegation'.
GO because... GO implement this in your AD DS environment.
>what are the side effects?
"there was one revelation in the guise of an ‘oh wow – I did not know that’ moment. NotPetya could use EternalBlue as a propagation method"
I like the footnote to the conclusion: "Noting is entirely risk free".
When attacking a remote service with domain admin credentials, the possibility to perform impersonation on the remote service (which still works, even when delegation is disabled) should be sufficient to completely subvert that remote machine. What doesn't (immediately) work, is continuing infections from the remote machine. It is maybe a little extra effort to loop the Kerberos ticket acquisition back to the original host, but certainly possible. Essentially, it raises the bar for the attacker, making a few mildly-interesting things more difficult to perform. But it doesn't really stop anything. One normally calls this "obscurity" rather than security.
The thing that is really worrisome about Active Directory, is a feature called "S4U2Proxy". It is sometimes also referred to as "Kerberos constrained delegation", although in reality, for a domain admin, it is exactly the opposite of constrained: it is a facility for unlimited arbitrary Kerberos ticket forgery. As domain admin, you can create an account with unrestricted S4U2Proxy privileges, start a process as that user, and then "Who do you want to be today?" with *NO* limits.
Not really a bug, the setting just hinders one of the attack vectors used, significantly slowing propagation, which given the exponential nature of propagation might increase the odds of detection and damage limitation before too many systems are taken down.
I have a suggestion that might help to reduce vulnerability to notPetya and similar malware, and it is to PATCH THE ETERNALBLUE VULNERABILITY ALREADY. The patch involved was released for every windows version in March of 2017, and the first time it became really obvious that that patch was important was in May. It's now been eighteen months. What excuse is there for leaving eternalBlue open for this long? Now every basic malware release uses it, because it's evidently still working. Fix it.
>What excuse is there for leaving eternalBlue open for this long?
Perhaps you are coming at this from the wrong direction. The NCC Group reports, unfortunately, don't comment on whether the client's network did or did not have fully up-to-date patched systems or not. I suspect from their articles the network did contain systems that were fully patched and running the latest AV software designed to detect NotPetya...
Disclaimer: Lax patching regime is not an excuse.
Have you ever worked in an old company or org? I mean a really old company that's been using Windows tech for more than 20 years? There's a ton of legacy stuff and the second you so much as decide to flip a single option on of off, let alone release a patch there's months and months of testing to be done. Some companies out there are only just getting off Win2008 DCs, some are still on them! They can't upgrade as their entire estate will stop working and that costs money. The sad fact is that they don't realise it will cost a heck of lot more if something nasty gets lose in the network!
Someone said to me the other day. Up until this point ( the last 12-18 months ) that most companies can live in their own secure bubble, they put up firewalls, packet inspectors and intrusion devices, basically putting up wooden boards on the windows of your house. Yet now with everyone pulling in connections to cloud services and outsourcing to external data centres those firewalls and devices are not going to secure enough. People must change their mindset, be more secuirty conscious, write better apps, consider security from the get-go, not as an afterthought as we have been able to.
Sadly we're human and out companies and our bosses don't see it like that. Spending more time than necessary on fivilious things like security costs money so they dismiss it. Sadly a false economy and sites like the Reg will fill with even more stories like Equifax as times goes on because security is not a dirty word, it's just boring to most.
A company where IT has quite a bit more input to business processes than we do here.
Honestly, this is a very proactive approach. It also puts everyone involved with IT security on the hot plate. While it would be uncomfortable to find out (maybe) you aren't as good as you thought you were, better to find out in controlled circumstances than with the Next Big Thing.
>Just what kind of company would intentionally infect itself with malware.
Looks like NCC EternalGlue will become a standard PEN testing tool - so in answer to your question, that will be any company that takes a proactive approach to security, which would most probably encompass all of NCC Groups cyber security clients.
Biting the hand that feeds IT © 1998–2020