Certificates help users, computers and services verify one another’s identities. They may support secure communications, user and device authentication, remote access, encrypted connections and other activities that depend on establishing trust.

In many environments, AD CS works quietly in the background. Employees may use certificates every day without realizing it, and even some technology teams may have limited visibility into why the service was originally installed.

It may have been introduced years ago to meet a specific technical requirement. A consultant may have configured it during an Active Directory deployment. A vendor may have required it as part of a larger system installation. In an industrial environment, it may have arrived within a preconfigured technology package supporting the operational network.

However it got there, the organization may now depend on it even if the people currently managing the environment weren’t involved in the original implementation or understand how it was configured.

That creates a common challenge: AD CS may be performing an important security function without receiving the focused security review it needs.

Why these weaknesses are easy to miss

Most security teams are familiar with the traditional vulnerability-management process.

A software vendor announces a vulnerability, releases an update and advises customers to patch the affected systems.

Many AD CS attack paths don’t fit neatly into that process because the issue often isn’t outdated software. It’s the way the service was configured.

A default certificate template may allow more access than intended. Enrollment permissions may be too broad. Approval requirements may be too weak for the type of certificate being issued. Another configuration may allow a standard account to request or obtain a certificate that can be used for more privileged authentication.

Because the service is still working, those conditions may not create an obvious warning. Users can authenticate, certificates are being issued and applications remain available. From an operational standpoint, everything may look normal, even though the configuration still leaves an exploitable path behind.

RMC finds these issues aren’t limited to unusual or careless deployments. They frequently appear in environments installed with default settings, common implementation practices or vendor-provided configurations. In some cases, AD CS may have been configured years ago to meet a specific need and simply remained in place as systems, teams and responsibilities changed.

Responsibility may also be divided among several parties. An internal IT team may manage Active Directory while a vendor supports the application that depends on it, or an OT environment may have been delivered as part of a larger industrial solution. Each party may understand its own piece of the system without anyone evaluating how those pieces connect into a larger attack path.

How basic access can become domain-level access

The specific technical steps vary, and later articles in this series will examine the most common attack paths in greater detail.

The broader concern is straightforward. An attacker may begin with a standard Active Directory user account. That initial access could come from compromised credentials, phishing, an infected device, a third-party connection or a legitimate account misused by a malicious insider.

From there, the attacker can examine the certificate services available in the environment and look for configurations that allow certificates to be requested or used in unintended ways.

A successful attack may allow that person to authenticate as a more privileged account. In a serious case, it can lead to domain administrator access. With administrative control of the domain, an attacker may be able to manipulate systems across the Active Directory environment, access restricted resources, deploy ransomware or establish additional ways to remain in the network.

That’s a significant outcome from what may have started as an ordinary user account.

It’s also why AD CS should be included when organizations evaluate their identity and access management (IAM) infrastructure. Reviewing passwords, privileged accounts and domain controllers is important, but it doesn’t provide a complete picture if certificate services are left out.

The same weakness can have different consequences in OT

AD CS is often discussed as an enterprise IT issue. For many RMC clients, that’s only part of the story.

Active Directory is also used throughout industrial environments. It may support authentication, administration, remote access or other functions within an OT network.

Some organizations maintain separate Active Directory environments for IT and OT. Others use shared or closely connected identity infrastructure.

When the same Active Directory environment reaches across both sides of the organization, an AD CS compromise can become an IT and an OT problem at the same time.

In a business network, domain compromise can affect email, financial systems, file storage, customer information and other essential services. An attacker may steal data, interrupt transactions or deploy ransomware across the environment.

In OT, the risk moves closer to the physical operation. Depending on which systems are connected to the domain and what protections surround them, elevated access could contribute to:

• Production interruptions
• Manufacturing or facility downtime
• Loss of access to operational systems
• Interference with physical processes
• Financial losses tied to unavailable production
• Safety concerns

Domain administrator access shouldn’t automatically give someone control over a physical process. Industrial organizations should have segmentation, access restrictions, safety systems and other safeguards that limit what an attacker can do.

But those protections aren’t always implemented consistently, and they shouldn’t be assumed without testing. The underlying AD CS weakness may look the same in IT and OT. The potential consequences change because of the systems and processes connected to the compromised environment.

Vendor-provided systems still need security testing

Industrial organizations depend on specialized vendors to provide systems that support complex operational needs. Those systems may arrive with Active Directory already configured. The vendor may set it up on the organization’s behalf or provide instructions for how it should be deployed. That can make implementation easier, but it may also create uncertainty around security ownership.

The organization may assume the vendor has already secured the environment. The vendor may expect the client to apply its own security standards. The internal security team may have limited access or may hesitate to change a configuration that could affect production or vendor support.

This doesn’t mean a vendor-provided system is inherently insecure. It does mean that preconfigured or vendor-supported Active Directory environments shouldn’t be excluded from independent review.

The same principle applies when internal teams closely follow standard Microsoft guidance. Documentation can help an organization install and operate a service, but a working deployment still needs to be tested against the attack methods security professionals are seeing today.

The question shouldn’t only be, “Was this system installed correctly?” Organizations should also ask, “Has someone tested what an attacker could do with it?”

What organizations should determine now

The first step is establishing whether AD CS is present and who is responsible for it.

Security and technology leaders should understand:

• Where AD CS is deployed
• Which business and operational systems depend on it
• Whether it was configured internally, by a consultant or as part of a vendor-provided system
• Whether IT and OT share or connect to the same Active Directory environment
• When certificate templates, permissions and enrollment processes were last reviewed
• Whether AD CS attack paths are included in internal network penetration testing
• What safeguards would limit the impact of domain compromise in OT

Organizations don’t need to treat every AD CS deployment as an active compromise. They do need to make sure they aren’t relying on assumptions based only on who installed it, how long it has operated or whether users are experiencing problems.

A service can run reliably for years while an exploitable configuration remains in place.

What’s next in this series

AD CS includes multiple documented attack paths, and each one involves different conditions, techniques and remediation steps. Trying to cover all of them in one article would either oversimplify the issue or create a technical resource that’s difficult for clients to use.

In the next parts of this series, RMC’s Commercial Security Division will take a closer look at the AD CS attack paths its consultants encounter most often during assessments. We’ll explain how those paths develop, what they may allow an attacker to accomplish and what organizations should consider when addressing them. We’ll also continue examining how the same weaknesses affect organizations differently when Active Directory supports both enterprise IT and industrial operations.

AD CS is a valuable part of many environments. But like any system built around identity and access, its security depends on whether the configuration can stand up to someone actively trying to misuse it.