Earlier this week I wrote about the Norwegian Company Hydro which was affected by ransom and needed to shutdown most of their operations. The ransomware was most likely distributed using Active Directory with Group Policy so it could spread across the organization –> https://msandbu.org/norwegian-hydro-affected-by-ransomware-attack-lockergoga/ also Kevin Beaumont wrote an extensive article on the subject as well –> https://doublepulsar.com/how-lockergoga-took-down-hydro-ransomware-used-in-targeted-attacks-aimed-at-big-business-c666551f5880
So imagine the scenario, an end-users machine was infected trough phising, using known tools the attackers managed to get the credentials of an domain admin and from there managed to distribute the ransomware across the organisation
The attack on Hydro was done using multiple attack vectors since Lockergoga didn’t have any good way to distribute from the infected source. Now looking back over the course of the last couple of years such as with Maersk as well which was afftected by Nonpetya which used an exploit in the SMB protocol to redistribute across the organization, we can see a trend. But how this was introduced in Hydro is still unknown.
Much of the targeted attack in large enterprises over the last couple of years is essentially leveraging the old way of managing resources with Active Directory, using built-in protocols with know exploits or an hijacked account. Where mosts enterprises have a built robust and large Active Directory infrastructure and managing much of the end-user computers using Group Policy in combation with other tools to handle package distribution. This has essentially been the default way to manage user & devices for many years, and of course the attackers know how to exploit it.
Now AD joined devices has been around for ages, where clients are placed and “belong” to an Active directory and controlled with policies from Group Policy and as part of this they also have direct communication with Active Directory Domain Controllers and SYSVOL folder to get a hold of the different policies and other pieces required to run logon scripts and such. As part of Active Directory they also have access to file shares, print servers, web servers internally and so on. Much of these attacks start with one user that has been affected by email, such as a phising mail.
A lot of enterprise applications have been built to leverage Active Directory as an identity provider to handle SSO to applications and files and to make it “user friendly” but from an administration perspective, the way to managing and distributing policies and the security model behind it hasn’t changed that much over the last couple of years. Of course there has been created numerous features in Windows Server and Active Directory to reduce attack surface and limit exposure –> https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack but from my experience many lack the knowledge / time or experience to implement and maintain much of the features. This also includes such as Resource domain where you have users in one domain and servers and infrastructure in another domain, which ill will be getting back to.
Much of the access here is based upon Active Directory rights and firewall rules in-place between the clients and the servers which are placed in the intra sone. Of course if an attacker manages to get a hold of an admin account using a known exploit, password sprawl or some other phising attack they can easily create or alter an group policy to distribute ransomware across the organization. Much of the attacks is trying to use exploits or leveraging legacy protocols to redistribute and to try and infect the most files/clients as possible as we saw with the Hydro attack.
Now there has been a lot of improvements in the SMB Protocol, Windows 10 Security Features and Locking down access, but with Group Policy we can still essentially knock everything out or disable all security features, allow use of legacy SMB protocols and essentially break havok. This can also of course be mitigated with proper access control such as with privileged accounts with workstations, but most organisations have not implemented MFA for altering Group Policy or proper JIT.
It is time to move away from AD based topology to Azure AD based topology?
So the point of this blog post, and something that I have been advocating for some time. If Hydro had Azure AD based clients would that have stopped the attack?
Moving clients to Azure Active Directory is a big shift and you can look at it as you would a resource domain, essentially moving clients out of the “comfort” of the enterprise and treating them as a internet based client. Moving to Azure AD also takes time to ensure proper management and also ensuring that users still can access applications as they would within Active Directory and getting SSO and such, but from a security perspective if gives a lot of free functionality. Moving to Azure AD also means that Group Policy is no longer an option for management and means that we need to look at other means such as Intune or other 3.party MDM.
Much of the tools for getting inside in a domain is based upon getting access to an client from an end-user perspective, and attacks such as Pass-the-hash and Golden Ticket is not going to work from an Azure AD based client. Secondly there are many tools that can be run from an client to do an Active Directory reconnaissance as well which is not going to work either.
Also with Microsoft now being an more of an security company there are many features now that is built on-top of Azure AD which gives also a lot more insight when it comes to security from an IT-admin perspective. Regardless if these tools/features require an license it gives us an overview of what’s going on and gives us direct insight and automatic remidiation on accounts that has been compromised.
- Intune
- Conditional Access
- Azure AD Identity Protection
- Cloud App Security
- Windows Defender ATP
- Azure ATP
Now also this move to Azure AD also indicates changing other functions such as File and Print. Moving to Office 365 and moving file collabaration there, which also reduces the attack surface since it reduces the attack surface in comparison to with SMB and file servers.
But I still need an Active Directory for Infrastructure?
Even if you still manage to get your clients out of the infrastructure and into Azure AD, you still have loads of server infrastructure which you need to manage and control and still requires Active Directory. So how would Azure AD clients still help?
Many attacks start with a compromised end-user account, so Azure AD can help for those type of attacks, but what if a domain admin is compromised? For the remaining infrastructure you should still follow Microsoft guidelines for securing your Active Directory but use it in combination of tools that you can get from the Cloud to manage identity and infrastructure
- Windows Defender ATP for Servers
- Azure ATP
- Log Analytics or Sentinel (for logging user activity)
- Password Hash Sync (to detected compromised accounts)
- Azure AD Password Protection)
- Implementing Azure AD MFA for supported workload/services
- Security Center.
So back to my initialy question, if Hydro had Azure AD based clients would that have stopped the attack?
Depending on how they got initially infected, yes most likely since just getting access to an endpoint in Azure AD does not give any of the same attack vectors as you would in a regular Active Directory enviroment. Initially I looked at Azure AD Clients from a feature perspective, but now I belive it’s time to look at it also from an security perspective.