CyberArk Labs is often asked to run risk assessments of target networks. This is similar to penetration testing, however, we focus primarily on testing threats and risks associated with privileged accounts. Based on this experience, we’ve created a risk assessment tool that automates and unifies our manual scans.
Meet zBang – a new open source tool designed to help security teams scan their networks and discover critical risks associated with privileged accounts:
https://github.com/cyberark/zBang
The tool is built from five different scanning modules:
- ACLight scan discovers the most privileged accounts that must be protected, including suspicious Shadow Admins.
- Skeleton Key scan discovers domain controllers that might be infected by Skeleton Key malware.
- SID History scan discovers hidden privileges in domain accounts with secondary SID (SID History attributes).
- RiskySPNs scan discovers risky configuration of SPNs that might lead to credential theft of Domain Admins
- Mystique scan discovers risky Kerberos delegation configuration in the network.
We launched zBang as a POC. To date, we’ve received good feedback on zBang’s scan results, so we’ve decided to publish it as an open source project as a way to help the broader security community.
Starting with ACLight
Let’s look at a typical risk assessment adventure to understand how zBang can help.
As a first step, we would like to know what the most privileged accounts in the scanned domain are. This is a fundamental question that can be answered using ACLight – one of the built-in modules in zBang. The unique thing about the ACLight scan is its capability to discover both known and unknown privileged accounts – otherwise known as “Shadow Admins” in the network.
The ACLight module queries the Active Directory (AD) for its objects’ ACLs and then filters and analyzes the sensitive permissions of each one. The result is a list of the most privileged accounts in the network (from the advanced ACL’s perspective of the AD). You can run the scan with any standard user; it could be a non-privileged user because it only performs legitimate read-only LDAP queries to the AD. The original ACLight GitHub repository is in https://github.com/cyberark/ACLight, and the new zBang tool provides a nice graphic visualization on top of the results.
Following is an example of a discovered privileged accounts list displayed on the zBang interface:
In the above figure, on the left side – we can see the “standard” privileged accounts that get their privileges due to their group membership. More interesting are the findings on the right side – these are “Shadow Admins.” These accounts get their privileges through direct ACL permissions assignment. They might be stealthier than the standard “domain admin” users, and therefore, they might not be as secure as they should be. Attackers often target and try to compromise such accounts.
In addition, zBang provides interactive graphic views on each of the privileged accounts and its sensitive permissions:
The different abusable ACL permissions are described in a small help page inside zBang and explained further in one of the popular BloodHound blog posts on “The ACL Attack Path” – link by @_wald0. Here is also a good place to say thanks to @harmj0y for his PowerView project that ACLight relies on for its ACL query functionality.
Three Questions for Evaluating Discovered Privileged Accounts
In our risk assessment engagement we ask three main questions on each of the discovered privileged accounts:
(1) Is the organization aware of the privileged account? It might be a legacy account or even might have been created with malicious intention.
(2) Can the organization reduce unnecessary permissions from that account? It’s highly recommended.
(3) Is the account fully secured? It should have strong and automatically rotated passwords, should be audited, and monitored for potential risky behavior.
When using zBang, after validating those three questions, we can mark the account with a “V” in the small selection box, and it will be colored in green. The goal is to make all the privileged accounts marked as secured with the green color.
Let’s discuss two examples for shadow admins that we saw in a few organizations, and they were kind of shocked by their discovery. The first is a user that is not a member of the Domain Admins group, but in fact, had one extra specific permission – the permission to add new members to this Domain Admins group. Therefore, it’s clear to understand that this user could add itself to the Domain Admins group whenever it desired – making it a super privileged user.
The second example we’ve observed several times is found users with a specific “reset password” permission over other domain admin accounts – and therefore they are privileged just like the other non-shadow admins. If an adversary were to compromise one of those shadow admins, it would be game over for the organization, because such an attacker could easily reset other admin accounts and impersonate them to accomplish his/her malicious intentions. Shadow admins should be identified and eliminated, if possible, or at least be well protected.
Skeleton Key
After identifying and securing the discovered privileged accounts from the previous step, we can progress to the next quick scan – searching for suspicious domain controllers that might be infected with the Skeleton Key malware.
Skeleton Key is a malware that infects domain controllers and allows an infiltrator persistence within the network. An infected domain controller will enable the infiltrator to access every domain account with a preset backdoored password set by the malware. In this instance, zBang’s scan will produce a visualized list of infected domain controllers with the Skeleton Key malware (if one exists):
If the scan finds an infected DC, it is crucial to initiate an investigation process.
More details on the threat are available at “Active Directory Domain Controller Skeleton Key Malware & Mimikatz” blog post by @PyroTek3 – link.
SID History
Moving forward to zBang’s third scan, it’s time to search for suspicious user accounts with two SIDs (security identifiers) – a primary SID and a secondary SID (sIDHistory). The SID history attribute is an attribute that can be assigned to each domain account and can be used in case of migration of an account between two trusted domains. The attribute can be manipulated by attackers to escalate privileges. Our goal in this scan is to discover hidden privileges in secondary SID of domain accounts, and the scan output will visualize the results as follows:
If the scan detects a privileged secondary SID – an investigation should be initiated. Especially if the account’s secondary SID is privileged and the main SID is not. This is a well-known attack method used for obtaining persistence in the target network and performing malicious actions in a stealthy manner. More details on the threat are available in the “Security Focus: sIDHistory” blog post by Ian Farr – link.
RiskySPNs
Step four of this potential risk assessment engagement is super critical. This step deals with risky configuration of SPNs (service principal names). Details on how to exploit Kerberos tickets and SPNs are well known and were discussed in one of our Labs blog posts (link) on “how to crack SPNs and achieve domain admin credentials”, and at link on “how to use SPNs as a persistence method” by @PyroTek3.
The tool scans one of the domain controllers for deployed services running with a high privileged user account. Those services can be targeted by infiltrating attackers to extract credentials and utilize the privileged account for malicious intentions. After running zBang’s RiskySPN module, we will get the risky network services that might allow the credential theft of privileged accounts. It will be visualized with the service and account names:
All the discovered services using user accounts (and not dedicated service accounts or machine accounts) that have SPN addresses must be well secured. If such an account is compromised, its registered service is compromised as well. You should consider converting the SPN to be registered under a machine account instead of a user account. Moreover, if a privileged account has an SPN (i.e., Domain Admin account), the registration of the SPN (the service) should be converted to a non-privileged account, and in any case, this account must be well secured. An attacker in that scenario can easily request a TGS (Kerberos service ticket) for that SPN and then brute force the ticket’s encryption – the extracted key is correspondent to the password hash of that SPN’s Domain Admin privileged account. It’s a powerful attack method used by adversaries to perform privilege escalation in the target network.
The Grand Finale – Mystique
The fifth and final scan module of zBang is called Mystique. This scan discovers risky delegation configurations in the network. The concept of delegation in general and how to exploit accounts that are allowed for delegation is a bit more complex, but we know attackers are using such methods that are published and available to everyone. You can see our explanations on the delegation threat here – link (“Weakness Within: Kerberos Delegation”), or @harmj0y, @tifkin_, and @gentilkiwi have researched those risky delegation permissions.
It’s important to realize how easy it is for attackers to abuse those delegation permissions. Consider that in nearly every real-world network scan we’ve performed with zBang Mystique to date, we’ve discovered multiple risky delegation issues. The Mystique scan output is a visualized list of the domain’s delegation options and their potential risks:
Delegation permissions in the network must be reviewed: Are the delegation permissions really necessary? Disable old and unused accounts trusted for delegation. In particular, check the risky delegation types of “Unconstrained” and “Constrained with Protocol Transition”. Convert “Unconstrained” delegation to “Constrained” delegation, so it will be permitted only for specific needed services. “Protocol Transition” delegation types must be revalidated and disabled, if possible.
Summary
Organizations and red teamers can utilize zBang to identify potential attack vectors and improve the security posture of the network. The results can be analyzed with the graphic interface or by reviewing the raw output files.
The new zBang tool discovers critical findings like:
- The most privileged accounts that must be protected, including suspicious Shadow Admins.
- Possible infected DCs with Skeleton Key malware.
- Suspicious SID history with hidden privileges.
- Risky configurations of SPNs that might lead to credential theft of domain admins.
- Risky Kerberos delegation configurations in the network.
It’s highly recommended to mitigate discovered threats. The different defense procedures are mentioned throughout this blog post.
For more information on zBang, check out the Quick Start Guide at: https://github.com/cyberark/zBang. Contact Asaf Hecht via email ([email protected]) or Twitter (@Hechtov) with any questions.
