Is Your Windows Environment Secure?
According to a couple sources, Microsoft Windows makes up between 70% and 80% of the footprint within data center. The vast majority of those installs will run Active Directory for their basic identity management solution, and even expand the usage beyond the Windows platform into the Linux world to provide a reduced footprint of end-user passwords. Windows Active Directory has indeed been an improvement over the legacy Windows NT Domain infrastructure, at least in some ways. However, there are some things we should learn from the Microsoft approach to security when implementing such tools. While it is not my intent to throw cold water in your face (despite the graphic), I do want to provide some facts of which you may not be aware. These facts may help steer your architectural discussion around the AD infrastructure, and ultimately around the data center as a whole.
Why use AD?
Let’s start with the most basic question. Why would we want to use Active Directory? Some may respond that it is more secure than having monolithic authentication schemes on each server or computer. While it is true that AD allows many important security features to be enforced enterprise-wide, I still vehemently disagree with the premise of this statement. Active Directory, when configured at its best, will ALWAYS be less secure than monolithic computers configured with equivalent features. I would even go as far as to say that AD is at most equally secure as monolithic computers without the equivalent AD security policies. There are several reasons that I make this very bold statement. First, in a monolithic world, your users are all configured explicitly. Even if they are configured with poor passwords, this creates an opportunity in which a single password will not work across the entire enterprise. AD, on the other hand, makes a same user and the same user password work wherever the user has access. Second, users which are created are done so with explicit intent. This means that simply adding a user to a group doesn’t suddenly enable them to access hundreds of computers, as can happen in AD. Third, a VAST majority of password hash replay attacks become far less useful on monolithic servers.
I hear you all saying, “So WTH Cliff? Are you actually suggesting that we don’t use an identity management solution like Active Directory?” No, I am not. However, we should be honest with ourselves, and understand the problems we are trying to solve. This allows us to understand and acknowledge the risks created by such a solution. AD is not designed to increase security. Rather, it is designed to decrease the workload in managing the enterprise. It would be completely impractical to run even a small environment without incorporating the features of AD. However, running AD, by nature, will give many users access to things that they may never need, cache credentials in places in which they should not be cached, and generally spread the authentication footprint FAR wider than is necessary for the environmental requirements. Additionally, as we will discuss, it creates some risks which, if you are not aware, can be deadly to your environment.
What can we learn from Microsoft’s history in security?
Now I know that this can be an emotional topic, but we must look at the facts and make rational decisions based on what they indicate. Setting aside the arguments around why certain decisions are made, we must accept that most vendors have a mindset around handling the balance between security and usability. For the majority of companies, we expect that balance to be at least in the middle, but always moving toward the security side. What do I mean by this? Let’s use, as an example, the default features of any installation of any product. For example, a default install of Ubuntu, doesn’t even have the SSH daemon enabled. The attack surface against most default Linux distributions is pretty small, even without running the built-in host-based firewall. With Windows, we as-an-industry have accepted (for whatever reason) the idea that usability is far more important that security. Thus, Windows products come with many usability features turned which make them useful, but also make them insecure. These features must be shut off in order to secure the environment. One very simple example would be the server service. This service supports some useful (required if you are within a domain) features, so it is hard to shut off without impacting functionality. However, this service also creates huge holes and allows access to the fundamental operating system.
In Microsoft’s defense, they have gotten much better, especially with the inclusion of Windows Defender (now called Microsoft Defender Antivirus). However, it’s hard to get excited about this minor addition, since windows has been around for just short of 40 years, and as often happens with Microsoft “features”, other 3rd party companies implemented Antivirus long before Microsoft had an offering.
Understanding the practical security boundary of an AD Domain
Another challenge around using AD is the concept of the practical security boundary. In Windows NT, the domain was the security boundary, and any connections between domains required trusts. The configuration was cumbersome, but did provide a means of sharing resources between desperate identity providers. However, in AD we have the new concept of the Forest. What many people do not know is that within a Forest, the trust relationship is always transitive, two-way. This means that unlike separate NT domains, within a Forest all identities have the ability to access any resources, given permissions. Lest you rely too heavily on those last two words, it is a very trivial exercise for an attacker to move from a domain administrator to an enterprise administrator. This means that if any domain within the forest is compromised, your entire forest must be considered compromised. This should toss some cold water on the age-old idea of putting “insecure environments” in their own domain. NO! That is a horribly bad idea. Those environments need to go into their own Forest. I debated on whether I would drop a video here, demonstrating how easy it is, as an attacker, to move around between domains, utilizing features fundamental to Windows AD. I decided against it. You will have to trust me, here. If your security team is unaware of this risk, please, for your own sake, have them do some research on this topic.
Unmasking the attackers
It is critically important to understand the risk to the environment. For example, we need to understand the attack surface—the ways that an attacker can gain unauthorized access to the environment or to important data. Also, although less important, it is useful to understand the possible attacker motivation, funding, available tools, and likely target industry sector. Active Directory is usually a post-breach consideration. In other words, most penetration tests which include AD are considered “assumed breach” tests, in which the question is answered, “If someone gets in, to what can they gain access?”
I would recommend reading through this report for more information and facts around historical breaches.
With all that discussion as a backdrop, let’s talk about detecting attackers within an AD environment. It is easy, and very incorrect, to believe that an attacker will be obvious by their actions. Actually, history proves this to be incorrect. Breaches, especially within large organizations, may go unnoticed for months or years. Many times, the first indication is when the company's data shows up on the dark web. That is not to imply that the attacker is not making noise; I am saying that the noise an attacker makes USUALLY sounds like just any other user within the environment, by leveraging features or tools which are vulnerable or poorly monitored.
An entire breach can occur with few, or no blips. Since we know that this is the case, this should raise awareness of blips on the RADAR. The real problem is that large enterprises can produce literally thousands of alerts a day. Knowing which are real, and which are just the maintenance guy forgetting his password again, is more of an art than a science. This is were the Security Information and Event Management (SIEM) system is supposed to play the most important role, but unfortunately it is prone to the same problems I will describe below in detection. Many organizations rely far too heavily on such systems, expecting them to reveal an attacker in glowing red. This likely will never happen unless the attacker is intentionally noisy. Just for giggles, let’s walk through a scenario to explain the point.
A simulated attacker
Let’s say an attacker gains access to a workstation through some means. The method is less important, but it could be through the user accidentally browsing to a compromised, similarly-named site, or just clicking a phishing email link. Either way, hopefully it is not too much of a stretch to believe that an attacker may gain access to a user’s laptop. Now what? Let’s assume the best-case scenario, that the user does not have administrative access to their own machine. The attacker can still get access to any passwords stored within the browsers or windows credentials vault. These are two sources which are still (unfortunately) frequently used by users. Regardless, the attacker can enumerate the entire domain with this level of access, including membership in all groups, all access rights, etc. Also, with some creative use of DNS, the attacker can make a logical map of the environment. The attacker may even download all service account hashes and begin to “kerberoast” them offline to crack the passwords. Just so you know, up until now, it is entirely possible that all of this activity has caused NO alerts.
First escalation
Let’s say that the attacker wishes to go for local administrator so that they can get the hash of the current user(s), and start moving laterally. Perhaps the attacker uses a vulnerable service and performs a privilege escalation. This may generate an alert, but probably not critical, depending on how it is done. Now, the attacker can acquire the hash of the logged in user, by dumping the LSASS process memory and evaluating it offline. We assume that our organization is running Local Administrator Password Services (LAPS) to generate random, generic passwords across the organization. Otherwise, pulling the password from the SAM Hive is rather easy, which would give the attacker access to every local computer in the environment. Let's assume we didn't make that mistake.
Lateral movement
Now that our attacker has the user’s hash, he can now begin to quietly map lateral movement paths. So far, we’ve only had one POSSIBLE alert for bouncing a service on a workstation, and possibly one alert for a change to the local administrator group. These alerts in a large environment are usually seen in the logs after the breach has been confirmed, data stolen, and headlines written. In other words, we still are not getting anything useful.
Escalation to Domain Admin
Let’s say that somehow our attacker is able to find a way to gain access to a shared resource via the already stolen credentials. This likely will not raise any flags, but the attacker can now gain the hashes of several more user accounts. With any fortune, our attacker now has access to an administrator account. So far, there have been no additional alerts, since all the attacker has done is log in with perfectly valid credentials.
Persistence to the Domain
The attacker has access to a lot of stuff, but to truly sell this access, he needs to establish some persistence. There are many ways to do this, many of which will never create an alert, and some of which are incredibly insidious. These methods can allow an attacker back into an environment even after all the passwords have been changed or accounts disabled. There may be an alert related to this activity, but it is unlikely even if there is, it was probably done a couple different ways in different places, so one alert may get action without actually plugging the persistence hole. By now, the attacker can start uploading the data from your most important databases, if they haven’t already.
领英推荐
Escalation to Enterprise Admin
Now our attacker moves from domain admin to enterprise admin, and gains access to every other domain within the environment. This MAY cause an alert, but it is possible that it would not. The attacker can now gain persistence within every domain, ensuring that it is almost impossible to lock them out. The attacker can download a full list of users, computers, etc., along with access to all your databases, etc. Of course, they already have all this information from the first step. Now, they can be a bit more noisy since they have a way back in no matter what you do.
So now your entire enterprise has been compromised, and practically speaking, you cannot stop the attacker that has gained access to certain credentials without a great deal of pain. There are so many places to check for persistence that it is a very tall mountain to climb in a large organization, and can be hidden in so many innocent looking activities.
At worst, this activity would generate four or five alerts, which will probably be spread over a few days.
Defining the problem
I want to propose a reason that the above activity can be so quiet. Kerberos, the backbone of Active Directory, attempts to service two opposite requirements at the same time. It wants to be the global catalog of enterprise resources and services (such as email, for example), which is important. However, it also wishes to be the database of record for security access. Because of the way in which these two opposing requirements interact, any authenticated user has access to a vast amount (nearly all) of data which literally reveals attractive targets. Is there a practical reason that any user should be able to enumerate the access a given group has over other objects within the domain? No, not really. But in some scenarios in which authentication engines use AD as the backing, the user used for this purpose must have a certain amount of access to the global catalog information. Again, Microsoft has erred on the side of usability over security. AD is extremely usable, but is also extremely insecure for even a novice attacker. As a result, tools try to patch the holes in the sieve. Tools include Managed Detection and Response (MDR)/Endpoint Detection and Response (EDR) suites, antivirus, dns/url filtering, email filtering, and even web sandboxing such as RBI, just to name a few. However, in my opinion, all of these tools suffer from the same general problem: The attack surface that they are protecting is too large and too prone to abuse. Allow me to explain further below.
Detecting the Attacker
Hopefully the above information has cast light on the fact that an attacker CAN be very quiet, but even if they are noisy it is hard to see the important alerts among the myriad of other alerts within the environment. Over the next few sections, let’s talk about how these tools detect bad programs or behavior, some of the weaknesses in detection, and the relevant gaps in protection. I am going to only list a couple options here, but they all will suffer from the same basic flaw.
Signatures
A “signature” is just a pattern which is HOPEFULLY unique to a certain type of action, file, behavior, etc. In detecting malware or hacker tools, many tools base their detection on signatures. This may be as simple as matching a string, or multiple strings of data within the executable. It could also include matching a hash of the file (MD5, for example) against a known list. A SIEM, likewise may alert based on signatures in logs such as log ID, message content, etc. Another example of a signature tool is url/dns filtering, which bases the filtering on a set of known good, known bad, or suspicious sites.
The big gap in these tools is that they can never stop a “zero day” attack, because signatures are based on “known bad” criteria. Such tools can be defeated rather easily. Changing anything in the program will change the hash. Altering the strings through obfuscation will make it not match any known value.
Behavior
A tool which tracks application or user behavior is a bit more sophisticated. It looks for certain things to happen in short succession. Therefore, it tries to maintain an intelligent understanding at “what is happening” for each session. Such tools can be defeated by breaking up the pattern, reducing the speed, adding jitter, or operating from different instances. These systems have the possibility of finding “zero day” attacks, but almost always will be configured to allow rather than cause an outage. Essentially, they will allow the suspicious tool to run until the confidence is high enough that it is malicious.
Sandboxing
This method tries to determine what an unknown tool or application is doing by running it a protected space in which the tool cannot cause problems. Tools can usually tell if they are running within a sandbox, and therefore change their behavior to avoid detection.
Catch Me If You Can!
I am not saying that the existing tools have no value; I am trying to help define the limits of their value. There are literally tools publicly available, written to help determine what is flagging on various applications or actions. Additionally, the funded attackers have access to the same MDR/EDR/XDR that you do, and are able to find a way to keep from raising alerts. Their tools will not show up because they have not been seen in the wild. The bottom line for all the tools and alerting is this: For the motivated, funded attacker, you will never see the alerts from any of your fancy tools because they will have already done the testing to ensure that alerts will not be raised. Why? Because, no matter how many signatures and behaviors your tools can track and detect, the attacker can write one more. Since, practically speaking, there is no limit to the number of variations which a user may use to write (and then obfuscate) a specific tool, there is always N+∞ number of variations available, where N is the number of behaviors and signatures you can detect. Your tools only work against well-known, publicly available tools and known behavioral patterns which are used by private attackers. Even here, there are publicly available tools for obfuscation which may defeat much of the security tools, even for the public attackers.
So? Now what?
I don’t want to leave you hopeless. I want to leave you with a sense of reality about your Active Directory environment. Too many companies base FAR too much hope on MFA. MFA is only useful in making stolen passwords less valuable, but they do not help if the session is also stolen. Also, MFA is usually not a thing with service accounts. So I am going to provide some ideas on how you can reduce the risk.
Summary
While there are many gaping holes in the way Active Directory is designed, it is possible administer the environment safer. However, this will require support from the entire executive management team, since security is a mindset and not a discipline. Because so much of the mission-critical information is stored and/or protected by Microsoft products and services, it is imperative that they be managed appropriately.
I hope that you have found this to be any combination of useful, enlightening, or entertaining. Please feel free to comment with any thoughts, suggestions, etc.
Thanks for reading.
The short answer is, NO.