Physical Access Is Still the Fastest Path to Domain Admin

Three hours. That's how long it took to go from standing outside a data center fence to dumping domain credentials from a VSS shadow copy.

Not three days. Not three weeks of patient phishing campaigns and careful lateral movement. Three hours, start to finish, in broad daylight.

The Setup

A client hired us for a physical target assessment of a remote data center. The engagement included a network penetration test component, but with a catch—we only got to touch the network if we could obtain physical access independently. No credentials provided. No VPN access. No "assume breach" scenarios. Get in on your own or go home.

They'd done penetration tests before. External testers couldn't get remote access unless they were provisioned with an account. Phishing had been attempted, but the results were limited—testers got low-privilege access and were discovered before they could do anything meaningful with it.

On paper, this looked like a reasonably mature security program.

The Perimeter

I started with the fence line around 2pm local time. Broad daylight, cars in the parking lot, normal business hours.

When I assess a perimeter, I'm not just looking for obvious holes. I use the six approach methodology—evaluating the facility from all six directions: north, south, east, west, above, and below. Most security assessments focus on the obvious entry points. Attackers look everywhere. What's the roof access situation? Are there utility tunnels? Can someone approach from an adjacent parking garage that overlooks your facility?

Beyond directional analysis, I run through CARVER targeting criteria for each potential entry point: Criticality, Accessibility, Recuperability, Vulnerability, Effect, and Recognizability. Originally developed for military target analysis, CARVER helps prioritize which weaknesses matter most. A gap in the fence behind a dumpster that leads directly to an unsecured network closet scores very differently than a gap that puts you in a courtyard with no building access.

I'm looking at how the facility relates to everything around it. Where does your property line meet a neighbor's? Are there elevation changes that make certain sections easier to approach? What about drainage culverts, loading docks, or maintenance access points? I'm looking at sight lines—where can someone approach without being observed from the building? I'm checking whether the fence fabric is properly secured at the bottom or whether I can just lift it up and roll under.

One design principle I see ignored constantly: your perimeter fence doesn't need to sit at the edge of your property line. In fact, it often shouldn't. Creating a buffer zone between public or neighboring space and your secured perimeter gives you standoff distance. That buffer creates space for detection before an attacker reaches your actual security boundary. It gives cameras and sensors more time to identify threats. It keeps your fence out of arm's reach from public sidewalks or neighboring properties where someone can work on it unobserved. When your fence shares a boundary with a neighbor's fence, you've eliminated that buffer entirely—you're trusting their security decisions to protect your perimeter.

In this case, I noticed their fence connected to a neighboring property's fence at one corner. The neighbor's fence was about two feet lower. No razor wire, no sensors, just a step up and a step down. Took about ten seconds. From a CARVER perspective, this scored high—easily accessible, low recognizability since it was in a blind spot between properties, and high effect since it bypassed all front-of-house security controls.

This is more common than you'd think. Fences get installed by different contractors at different times. Property boundaries create weird angles. Nobody walks the full perimeter regularly, so gaps that develop over time go unnoticed. A fence that was secure when it was installed five years ago might have a section that's been damaged by weather, undermined by erosion, or compromised by changes on an adjacent property.

Cameras were installed at the perimeter. I walked right past them. They weren't actively monitored.

Why "We Have Cameras" Isn't a Security Control

There's a fundamental difference between cameras as a deterrent, cameras as a forensic tool, and cameras as an active security control.

As a deterrent, cameras work on opportunistic threats—someone who might consider hopping a fence but decides against it when they see a camera pointed at them. Professional attackers assume cameras exist and plan accordingly. We wear generic clothing, avoid looking directly at cameras, and move with purpose like we belong there. Deterrence value against a motivated attacker is close to zero.

As a forensic tool, cameras help you understand what happened after a breach. That's valuable for incident response and prosecution, but it doesn't prevent the breach itself.

As an active security control, cameras only work if someone is watching in real-time and can trigger a response before the attacker achieves their objective. In my experience, maybe one in ten facilities with "monitored" cameras actually has someone watching who can respond in time to matter.

Most security operations centers are monitoring dozens or hundreds of camera feeds. They're watching for obvious anomalies—someone running, a vehicle where it shouldn't be, a door propped open. A person walking calmly across a parking lot in business casual doesn't register as a threat.

Making Perimeter Security Actually Work

The fix here isn't necessarily more technology. It's process and verification.

Walk your full perimeter at least quarterly. Don't delegate this to someone who sees it every day—bring in fresh eyes who will notice things that have become normalized. Document everything with photos and GPS coordinates. Pay special attention to where your property interfaces with neighboring properties, public rights-of-way, and natural features.

If your fence connects to a neighbor's fence, you have a shared security boundary that you don't fully control. Either extend your fence to create a complete perimeter, or coordinate with the neighbor on shared security standards. Neither option is cheap, but neither is a breach.

For cameras, answer this question honestly: if someone walked onto your property right now, what would actually happen? Not what's supposed to happen according to your security plan—what would actually happen? If the answer is "we'd have footage of it tomorrow," your cameras are forensic tools, not security controls. That's fine, but don't pretend they're preventing anything.

If you want cameras to function as an active control, you need monitoring with defined response protocols and regular testing. Run drills where someone approaches the perimeter and verify that the monitoring team detects them and initiates response within a defined time window. If you can't pass that test consistently, adjust your expectations about what the cameras are actually doing for you.

The Door

Once inside the perimeter, I found an external office space attached to the facility.

Standard commercial lock on the door. Picked it in under a minute.

Now I'm inside, standing in an office with workstations. Still haven't touched a keyboard.

Why Most Commercial Locks Are Security Theater

The lock on that door was a standard pin tumbler lock—the same basic technology that's been in use for over a century. I used a pick gun, which is a mechanical device that bumps all the pins simultaneously and can open most standard locks in seconds. Someone with basic training and a $30 tool from Amazon can do the same thing.

This isn't exotic tradecraft. Locksport is a hobby community with YouTube tutorials and practice lock kits. Bump keys work on the majority of residential and commercial locks. Electronic bypass tools can defeat many keypad locks. The locks that most facilities rely on are speed bumps at best.

I should be clear: I'm not saying locks are useless. They establish a legal boundary—bypassing a lock demonstrates clear intent to gain unauthorized access, which matters for prosecution. They deter casual intrusion. They keep honest people honest. But if your security plan assumes a locked door will stop a motivated attacker, you're working with a flawed assumption.

Upgrading Physical Access Controls

High-security lock cylinders from manufacturers like Abloy, Medeco, or Mul-T-Lock are significantly more resistant to picking, bumping, and bypass attacks. They cost more, but for sensitive areas, the upgrade is worthwhile.

Better yet, move to electronic access control for any door that protects something valuable. Key cards, fobs, or mobile credentials give you centralized logging, the ability to revoke access instantly, and integration with your security monitoring. When someone badges into a sensitive area at 2pm on a Tuesday, you have a record. When someone picks a mechanical lock, you have nothing.

For the highest-security areas, implement multi-factor access: something you have (badge) plus something you know (PIN) or something you are (biometric). Layer this with mantraps or airlocks where appropriate.

But technology alone isn't enough. A door with a $500 high-security lock is worthless if someone props it open with a trash can, which I see constantly. Door prop alarms with escalating alerts are cheap and effective. Integrate them into your monitoring.

Finally, consider intrusion detection beyond just the doors themselves. Motion sensors, glass break detectors, and pressure sensors can alert you to unauthorized access even if someone defeats or bypasses the door hardware.

The Network

Here's where organizations usually assume attackers get stuck. Network access control, device authentication, segmentation—all the things that are supposed to keep unauthorized devices off the network.

I walked up to a workstation and looked at the back. Asset tag with the MAC address printed right on it.

Spoofed the MAC on my laptop, plugged into the network jack. I was on.

Why MAC-Based Network Access Control Fails

A lot of organizations implement Network Access Control and think they've solved the rogue device problem. The most common implementation is MAC address filtering—maintaining a whitelist of approved device MAC addresses and blocking everything else.

The problem is that MAC addresses aren't credentials. They're identifiers. And they're identifiers that the device itself reports to the network. If I can find out the MAC address of an approved device, I can configure my attack laptop to report that same address. The switch can't tell the difference.

Organizations make this easy in several ways. Asset tags with MAC addresses printed on them, like I found here. Inventory spreadsheets on shared drives. DHCP logs that anyone on the network can query. ARP tables that show MAC-to-IP mappings for all active devices. Even if you're not printing MACs on stickers, an attacker with brief physical access to any workstation can get the MAC from the operating system in seconds.

The fundamental issue is that MAC authentication treats "something a device claims about itself" as proof of identity. That's not authentication—it's a polite request.

Network Access Control That Actually Works

802.1X with certificate-based authentication changes the equation. Instead of trusting what the device claims, the network verifies a cryptographic certificate that the device can't easily forge. The certificate is tied to a private key stored on the device, and the network challenges the device to prove it has that key. You can't spoof this by looking at a sticker.

Implementing 802.1X isn't trivial. You need a certificate authority, a RADIUS server, and a deployment mechanism to get certificates onto all your legitimate devices. You need a process for handling exceptions—what happens when a printer or IoT device can't support 802.1X? You need a guest VLAN for visitors that's properly segmented from your production network.

But once it's in place, plugging a rogue device into a network jack gets you onto the quarantine VLAN with no access to anything useful, instead of landing you on the production network with a valid IP address.

If full 802.1X deployment isn't feasible, there are intermediate steps that help. Network monitoring that alerts on new MAC addresses appearing on the wire. Automatic isolation of unknown devices pending review. Regular correlation between network device inventory and active MAC addresses on switches to identify unauthorized additions.

At minimum, stop printing MAC addresses on asset tags. There's no operational reason that information needs to be visible on the outside of the device.

The Credentials

Once on the network, I fired up Bettercap and Responder-NG. Within an hour, I had captured credentials for several users.

How LLMNR/NBT-NS Poisoning Works

Windows networks have a name resolution hierarchy. When a system needs to find another system by name, it first checks its local hosts file, then queries DNS. If DNS doesn't have an answer, the system falls back to older protocols: Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS).

Here's the problem: LLMNR and NBT-NS are broadcast protocols. When a system uses them, it's essentially shouting to everyone on the local network, "Hey, does anyone know where 'fileserver01' is?"

Responder exploits this by listening for those broadcasts and answering all of them: "Yes, I'm fileserver01, send your traffic to me." When the victim system tries to connect to what it thinks is a legitimate server, it sends authentication credentials to the attacker.

The credentials are typically NTLMv2 hashes—not plaintext passwords, but cryptographic hashes that can be cracked offline or relayed to other systems. Against weak passwords, cracking is trivial. Against strong passwords, it takes longer but is often still feasible given enough time and GPU power.

What makes this attack so effective is that it's completely passive from the network's perspective. I'm not scanning, I'm not exploiting vulnerabilities, I'm not doing anything that looks like an attack. I'm just answering questions that Windows systems are asking constantly, all day, every day.

This happens for legitimate reasons all the time. Someone mistypes a server name. A mapped drive references a server that's been decommissioned. A system tries to find a resource that only exists on a different network segment. Every time Windows can't resolve a name through normal channels, it broadcasts the request, and an attacker can answer.

Shutting Down LLMNR/NBT-NS Attacks

The most effective fix is to disable LLMNR and NBT-NS entirely. These are legacy protocols that exist primarily for backward compatibility with very old systems. Modern networks shouldn't need them. Disable LLMNR via Group Policy (Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution).

Disable NBT-NS on each network adapter or via DHCP options.

Before you do this, test in a non-production environment. Some legacy applications may depend on these protocols, and disabling them without testing can break things in unexpected ways. Identify any dependencies and migrate them to proper DNS resolution before flipping the switch in production.

Enforce SMB signing across your environment. This doesn't prevent credential capture, but it prevents NTLM relay attacks where an attacker uses captured credentials in real-time to authenticate to other systems.

Monitor for Responder-style attacks using network detection tools. The pattern of a single host answering every LLMNR query is distinctive and should trigger an alert.

Implement strong password policies that make offline cracking impractical. A 16-character random password takes exponentially longer to crack than an 8-character password with complexity requirements. Even better, move to passwordless authentication where feasible.

The Privilege Escalation

One of those users had domain admin rights.

Not because they needed them. Not because their role required that level of access. Just sloppy privilege management—someone in IT who had accumulated permissions over time and never had them right-sized.

How Privilege Creep Happens

Privilege creep is insidious because each individual decision seems reasonable at the time. An IT person needs domain admin to fix a problem after hours when no one else is available. They get the rights and solve the problem. Nobody thinks to remove the rights afterward.

A help desk technician gets added to a privileged group temporarily to cover for someone on vacation. Temporary becomes permanent.

Someone changes roles within IT but keeps all their old access while gaining new access for their new role. After a few role changes, they've accumulated the union of permissions from every position they've ever held.

IT staff are the most common culprits because they have the access to grant themselves permissions and the knowledge to do it without triggering obvious alerts. But it happens everywhere—developers with production access they no longer need, former project team members who still have rights to sensitive systems, service accounts created years ago with excessive permissions because it was easier than figuring out the minimum required access.

The result is that most environments have far more privileged accounts than they realize. When I compromise any one of those accounts, I don't need to escalate privileges—the privileges are already there.

Getting Privileged Access Under Control

Start with discovery. You need to know who actually has privileged access before you can manage it. Enumerate all members of Domain Admins, Enterprise Admins, Schema Admins, and local Administrators groups across your environment. Include nested group membership—an account that's a member of a group that's a member of Domain Admins is a domain admin.

For each privileged account, document the business justification. If you can't articulate why a specific person needs domain admin rights, they probably don't.

Implement tiered administration. Microsoft's Red Forest/ESAE model and the newer Enterprise Access Model both provide frameworks for separating privileges by tier. Tier 0 accounts that can control the domain should be different from Tier 1 accounts that manage servers, which should be different from Tier 2 accounts that support workstations. An attacker who compromises a workstation admin shouldn't automatically get domain admin.

Use just-in-time (JIT) privileged access. Instead of permanent group membership, administrators request elevated rights when they need them, the rights are granted for a limited time window, and they automatically expire. This reduces the window of opportunity for attackers to leverage compromised credentials.

Put your most privileged accounts in the Protected Users security group. This disables insecure authentication protocols and prevents credential caching, making those accounts harder to exploit even if they're targeted.

Conduct regular access reviews. Quarterly, at minimum, review all privileged group membership and verify that each account still needs the access it has. Make this someone's explicit responsibility with accountability for completion.

The Dump

With domain admin credentials, I accessed a domain controller and performed a VSS shadow copy dump. This gives you the NTDS.dit file—the Active Directory database containing every user's password hash in the environment.

Took those offline and started cracking.

From fence breach to complete credential compromise: two hours and forty-seven minutes.

What Attackers Get From NTDS.dit

The NTDS.dit file is the crown jewels of an Active Directory environment. It contains the password hashes for every user account in the domain—not just active users, but service accounts, disabled accounts, historical accounts that haven't been cleaned up.

Once an attacker has this file and the associated SYSTEM registry hive, they can extract hashes for offline cracking with no risk of account lockout, no network traffic to detect, and unlimited time and compute resources.

Password hashes can be cracked or used directly in pass-the-hash attacks against systems that accept NTLM authentication. Even if you have very long, complex passwords, the attacker can use the hashes to authenticate as any user to any system that accepts NTLM.

The attacker can also extract the KRBTGT account hash, which enables Golden Ticket attacks—forged Kerberos tickets that grant access to anything in the domain for as long as the attacker wants, even if you change every user password in the environment.

Recovering from a Golden Ticket compromise requires resetting the KRBTGT password twice, which has its own operational challenges.

Protecting Domain Controllers and Detecting Credential Theft

Domain controllers should be your most protected systems. Physical access should require multiple factors and be logged. Network access should be limited to necessary administrative traffic from hardened jump servers. No one should be browsing the web or checking email from a DC.

Monitor for Volume Shadow Copy operations on domain controllers. The specific sequence of creating a shadow copy, accessing the NTDS.dit file, and copying it off the system is distinctive. Microsoft Defender for Identity, Microsoft Advanced Threat Analytics, and various SIEM solutions can detect this pattern.

Implement credential tiering so that domain admin credentials are never exposed on lower-tier systems. If a domain admin's credentials are only ever used on Tier 0 systems, compromising a workstation doesn't give the attacker domain admin hashes to capture.

Consider deploying Credential Guard on systems that support it. This uses virtualization-based security to protect credential storage, making it significantly harder for attackers to extract hashes from memory.

For the KRBTGT account specifically, rotate the password periodically (Microsoft recommends at least annually) and ensure you have a documented process to reset it twice in case of suspected compromise.

Finally, have a credential compromise response plan. If you discover that NTDS.dit has been exfiltrated, you need to be prepared to reset passwords for your entire environment. That's a massive undertaking—know in advance how you'll prioritize, communicate, and execute.

The Response

When I presented the findings, the client's response was telling.

They downplayed the impact. Their reasoning? "No one ever attacks an organization the way you did."

I've heard this before. It's the most dangerous assumption in security.

The Reality

Here's what actually happens in the real world:

Nation-state actors conduct physical surveillance as standard tradecraft. Russian GRU officers were caught attempting to hack the OPCW headquarters by setting up WiFi interception equipment in a car parked outside the building. Chinese intelligence has been documented conducting physical reconnaissance of data centers and telecommunications facilities.

Organized crime groups pay insiders and contractors for physical access. The 2020 attempted bribery of a Tesla employee to install malware is a documented example—a million-dollar offer to plant ransomware via physical access.

Ransomware gangs have evolved beyond pure remote access. As organizations have improved their email security and endpoint detection, some groups are exploring alternative initial access vectors, including physical approaches for high-value targets.

A significant percentage of major breaches involve some physical component that defenders never planned for. Stolen laptops with cached credentials. USB drops in parking lots. Social engineering of front desk staff to get a "vendor" into the server room.

The idea that attackers will politely stay on the internet and only use techniques that your external pen test covers is a fantasy.

This client had invested in external penetration testing. They'd done phishing assessments. Those tests found limited impact because the testers were working within constraints that real attackers don't have.

Meanwhile, a two-foot height difference in a fence and a MAC address printed on a sticker gave me the keys to their entire domain in an afternoon.

What This Actually Means

Most security programs treat physical and cyber as separate domains. Physical security handles badges and cameras. IT security handles firewalls and endpoints. Red team assessments usually pick one lane or the other.

Attackers don't think this way. They look for the path of least resistance, wherever it exists.

If your network penetration test starts with "assume the attacker has internal network access," you're skipping the part where they actually have to obtain that access.

Sometimes that's appropriate for scoping. But if you've never tested whether someone can actually get onto your network without help, you have a blind spot.

Some questions worth asking:

• When was the last time someone walked your entire perimeter looking for gaps?

• Are your physical security systems actually monitored, or just recorded for post-incident review?

• If someone plugged an unauthorized device into a network jack in a low-traffic area, would you know?

• Do you know which users have domain admin rights, and can you justify each one?

• If you discovered tomorrow that your NTDS.dit had been exfiltrated, do you have a response plan?

• Has your red team ever been told "get in however you can" with no constraints?

The Uncomfortable Truth

The client in this story had done the things you're supposed to do. External pen tests. Phishing assessments. Cameras on the perimeter. Locks on the doors.

None of it mattered because they'd never tested how these controls work together against someone who doesn't follow the rules of engagement that make security assessments manageable.

The fence gap had been there for years. The MAC address stickers were standard practice. The over-privileged IT account had probably existed since that person's second week on the job.

Each one was a small thing. Together, they were three hours from zero access to total compromise.

If you want to know how an actual attacker would approach your environment, you have to let someone try. No pre-provisioned access. No assumed breach starting points. No artificial constraints that exist to make the test easier to scope and execute.

Otherwise, you're testing your security program against a version of reality that doesn't exist.

I do a limited number of these integrated physical/cyber assessments each quarter. If you're curious what a realistic attack path into your environment might look like, grab 30 minutes on my calendar. I'll walk you through how we scope these engagements and what we typically find.

Keith Pachulski

Red Cell Security, LLC

keith@redcellsecurity.org

www.redcellsecurity.org

📅 Book time with me: https://outlook.office365.com/book/redcellsecurity@redcellsecurity.org/