> root@satellite:~# traceroute dc01.corp.hq.local — 1 hop via ipsec0<span class="cursor-blink">_</span>_
The head office was impressive. Three floors of a modern commercial building in a city centre, housing four hundred staff, a well-resourced IT team, a properly configured data centre, and a security posture that reflected years of investment. Endpoint detection and response on every workstation. Network segmentation with enforced firewall rules. Privileged access workstations for domain administration. A SIEM collecting and correlating events from across the estate. Regular penetration testing. The organisation took security seriously, and it showed.
Two hundred miles away, above a retail unit on a high street, sat the satellite office. Twelve staff. One IT cupboard. A consumer-grade router. A single flat network. No EDR. No SIEM. No segmentation. No on-site IT support. The office existed because the company had acquired a small regional firm five years earlier and had retained the location for client proximity.
Between these two environments — one hardened, one not — ran a site-to-site IPsec VPN tunnel. It had been established during the acquisition to join the satellite office to the corporate Active Directory domain. It carried authentication traffic, file share access, email, and printing. It had been configured once, documented once, and never reviewed.
The tunnel treated both ends as equals. The head office's security posture was irrelevant. We did not need to breach it. We breached the satellite office instead, and the tunnel carried us straight through.
The client had engaged us for their annual penetration test. In previous years, the scope had been limited to the head office — the location where the IT team was based, the data centre was housed, and the perceived risk was concentrated. This year, at our recommendation following a scoping discussion about attack surface, the client agreed to extend the scope to include the satellite office.
The engagement was structured as two concurrent workstreams. One tester was deployed to the head office with an assumed-insider position on the user VLAN. A second tester — the author of this article — was deployed to the satellite office with the same assumed-insider positioning. The objective was to determine whether the satellite office could be used as a viable attack path into the head office environment, and if so, to demonstrate the extent of access achievable.
The rules of engagement were standard: no denial of service, no data destruction, immediate notification of any critical findings that posed an imminent business risk. Both testers operated independently and did not share findings during the assessment, ensuring that each attack path was evaluated on its own merits.
Arriving at the satellite office was immediately instructive. The office occupied the first floor above a retail unit, accessed via a street-level door and a narrow staircase. The door was secured with a standard five-lever mortice lock — no access control system, no intercom, no CCTV. A small sign beside the door bore the company name.
The office interior was open-plan: twelve desks, a small meeting room, a kitchenette, and a utility cupboard that served as the IT room. The utility cupboard was unlocked. Inside it sat the entirety of the satellite office's network infrastructure.
The contrast with the head office was stark. The head office had a dedicated server room with biometric access control, redundant power, environmental monitoring, and enterprise-grade network equipment. The satellite office had an unlocked cupboard with consumer-grade equipment, an unmanaged switch incapable of VLANs, and a wireless passphrase written on a sticker.
Every device in this office — workstations, printer, NAS, wireless clients — sat on a single flat 192.168.1.0/24 network. There was no segmentation. There was no monitoring. There was no EDR. And from this single flat network, an IPsec tunnel provided direct connectivity to the head office.
We connected our assessment laptop to a spare port on the unmanaged switch and received a DHCP lease on 192.168.1.0/24. No 802.1X. No MAC filtering. No port security. The switch was unmanaged — these controls were not technically possible.
Our first objective was to understand the VPN tunnel — what it connected, what it permitted, and what controls, if any, governed traffic traversing it. We began with the router.
The router's web management interface was accessible on the default IP of 192.168.1.1. The administrative credentials were the manufacturer's defaults — unchanged since installation. The router had been configured by an IT contractor during the original office setup five years earlier and had not been touched since.
The VPN configuration told us everything we needed to know. The tunnel was configured with IKEv1 using 3DES encryption and MD5 authentication — both cryptographic choices that have been deprecated for years. Perfect Forward Secrecy was disabled, meaning that compromise of the pre-shared key would allow decryption of all past and future traffic. The pre-shared key itself was a dictionary word followed by a year — twelve characters, trivially guessable.
But the most significant finding was the tunnel's traffic policy. The VPN permitted the satellite office's entire 192.168.1.0/24 network to reach five subnets at the head office — the server VLAN, the user VLAN, the voice VLAN, the management VLAN, and the DMZ. There were no restrictions on ports, protocols, or source hosts. Any device on the satellite office network could communicate with any device on any of these five head office subnets, over any protocol, without restriction.
The tunnel had been configured five years ago to 'just work'. Nobody had revisited the access policy since. The satellite office needed access to Active Directory, file shares, and email. Instead of granting access to specific services on specific hosts, the configuration granted access to everything.
The site-to-site VPN tunnel permitted unrestricted access from the satellite office network to five head office VLANs, including the server and management networks. No port, protocol, or host restrictions were applied. The tunnel had been established for 847 days without review.
We confirmed our access to the head office networks by performing targeted scans through the VPN tunnel. We were cautious — the head office had a SIEM and potentially an IDS/IPS, so we kept our scan rate low and our initial queries focused on known service ports.
From an unlocked cupboard in a satellite office two hundred miles away, we could reach the head office's domain controllers, file servers, management interfaces for the core switch and firewall, the ESXi virtualisation hosts, the wireless controller, and — with particular irony — the SIEM appliance that was supposed to be detecting attacks.
The management VLAN was especially concerning. This network was designed to be isolated — accessible only from dedicated management workstations within the head office. The security team had implemented strict access controls from the head office's user VLAN to the management VLAN. But nobody had considered that the management VLAN was also reachable from the satellite office via the VPN tunnel. The access controls at the head office were bypassed entirely by traversing the tunnel from a location where no such controls existed.
Before pivoting through the tunnel, we needed valid domain credentials. The satellite office's minimal security posture made this straightforward.
The satellite office workstations were domain-joined but running without EDR — the head office's EDR licence covered only the head office endpoints, and the satellite office had been excluded from the deployment scope due to 'budgetary constraints'. The workstations were running Windows 10 with local administrator accounts managed by the head office's LAPS deployment — a positive control. However, other avenues were available.
The NAS device in the IT cupboard was our first target. It was accessible via SMB on the local network with a guest account — anonymous read access was enabled on a share named Office. The share contained a miscellany of files accumulated over five years: scanned invoices, staff rotas, meeting notes, and — in a folder named IT Setup — documentation from the original office configuration.
A plaintext file containing domain credentials, stored on a NAS with anonymous access, in an unlocked cupboard, in an office with no access control. The file had been created five years ago by the IT contractor who set up the office. It had never been removed.
The svc_domainjoin account was a domain service account created specifically for joining workstations to the domain at the satellite office. We tested the credentials against the domain controller — they were still valid. The password had not been changed since 2019.
With a valid domain account, we began authenticated enumeration of the Active Directory environment. The svc_domainjoin account was a standard domain user — but in Active Directory, standard domain user access is sufficient to enumerate the entire directory structure.
We used BloodHound to map the domain's attack paths. BloodHound collects information about Active Directory objects — users, groups, computers, sessions, ACLs — and visualises the relationships between them, highlighting paths from any compromised account to high-value targets such as Domain Admins.
BloodHound's analysis revealed several attack paths from our current position. The most direct involved the svc_domainjoin account itself. The account had been granted the ability to join computers to the domain — a standard and expected privilege. However, it had also been granted the ability to modify the properties of computer objects it had created, including the ability to configure resource-based constrained delegation on those objects.
This is a well-documented privilege escalation path. An account that can modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on a computer object can configure that computer to accept delegation from an attacker-controlled account, enabling the attacker to request service tickets as any user — including domain administrators — for services on that computer.
But BloodHound also revealed a simpler path that did not require any exploitation. It showed us where privileged users were logged in.
BloodHound's session collection identified that a member of the IT Infrastructure team — a group with Domain Admins membership — had an active session on a workstation at the satellite office. The workstation was SAT-WS04, assigned to a staff member who split their time between the head office and the satellite location.
The staff member was not in the office during our assessment — their desk was empty, their monitors dark. But their workstation was powered on, locked at the Windows login screen, with an active domain session running in the background. The IT infrastructure team member had logged in remotely via RDP to perform maintenance on the machine the previous week, and their session had not been terminated.
The workstation was on the same flat 192.168.1.0/24 network as our assessment laptop. There was no network-level separation between us and the machine hosting a domain administrator session. The machine did not have EDR installed.
We needed local administrator access to the workstation to extract the cached credentials. LAPS was deployed, so the local admin password was unique to this machine and stored in Active Directory. However, our svc_domainjoin account did not have rights to read LAPS passwords. We needed another approach.
The workstation was running Windows 10, version 1909 — a build that was over two years out of support. We identified that it was missing the patch for CVE-2021-36934 (HiveNightmare/SeriousSAM), which allows a standard user to read the SAM, SYSTEM, and SECURITY registry hives from Volume Shadow Copies. This vulnerability permits local privilege escalation without requiring any existing administrative access.
The Volume Shadow Copy contained a copy of the SAM hive from before the most recent LAPS password rotation. We tested the extracted local administrator hash against the workstation — it was still valid. LAPS had rotated the password after the shadow copy was created, but the old hash in the shadow copy had not been invalidated because the shadow copy itself was never cleaned up.
With local administrator access to SAT-WS04, we extracted the cached domain credentials from memory using Mimikatz. The IT infrastructure team member's domain administrator credentials were present in LSASS — their RDP session was still active in the background.
With a domain administrator NTLM hash, we performed a pass-the-hash attack against the primary domain controller at 10.0.1.10 — two hundred miles away in the head office data centre, reached through the site-to-site VPN tunnel from the satellite office's unlocked IT cupboard.
SYSTEM-level access on the primary domain controller. We confirmed the compromise with a DCSync, extracting all domain password hashes including the krbtgt account. The head office's hardened data centre, its firewalls, its segmented VLANs, its EDR deployment, its SIEM — none of it mattered. The attack did not traverse any of those controls. It came in through the back door, along a tunnel that had been left wide open since 2019.
Our colleague at the head office, working independently, had a very different experience. The head office environment was well-defended. EDR blocked several common attack techniques. SMB signing was enforced, preventing relay attacks. LAPS was deployed and functioning. The SIEM generated alerts on suspicious authentication patterns. Network segmentation prevented direct access from the user VLAN to the management and server VLANs.
After five days of testing, the head office tester had achieved local compromise on a single workstation via a misconfigured software deployment package — but had been unable to escalate to domain-level access. The EDR detected and blocked Mimikatz execution. The network segmentation prevented direct access to the domain controllers. The SIEM flagged the suspicious activity and the IT team were investigating.
The head office, tested on its own merits, was resilient. But the head office was not an island. It was connected to a satellite office that had none of the same protections, via a tunnel that carried trust implicitly.
One tester was blocked by years of security investment. The other achieved domain compromise in under a day from an unlocked cupboard. The difference was not skill — it was geography.
| Step | Action | Weakness Exploited |
|---|---|---|
| 01 | Connected to satellite office network via unmanaged switch | No 802.1X or port security; unmanaged switch incapable of controls |
| 02 | Accessed router admin panel with default credentials | Default credentials unchanged for five years |
| 03 | Mapped VPN tunnel — unrestricted access to five head office VLANs | VPN configured with ALLOW ALL; no port/protocol restrictions |
| 04 | Retrieved domain credentials from NAS share (anonymous access) | Plaintext credentials on anonymously accessible SMB share |
| 05 | Enumerated domain via BloodHound; identified admin session at satellite | Domain admin RDP session left active on satellite office workstation |
| 06 | Exploited CVE-2021-36934 for local privilege escalation | Workstation running unsupported Windows build; missing critical patches |
| 07 | Extracted domain admin credentials from LSASS via Mimikatz | No EDR on satellite office workstations; cached admin credentials |
| 08 | Pass-the-hash to DC01 via VPN tunnel; DCSync | Unrestricted VPN tunnel; no controls on DC access from satellite |
This engagement demonstrates a principle that is fundamental to security architecture but routinely overlooked in practice: a trust relationship inherits the risk profile of the weakest participant.
When the head office established a site-to-site VPN with the satellite office, it implicitly extended its security perimeter to include every device on the satellite office network. The head office's firewalls, EDR, SIEM, and segmentation became irrelevant for any traffic traversing the tunnel, because that traffic entered the head office environment behind all of those controls.
The most urgent remediation was restricting the VPN tunnel's access policy. The satellite office required access to Active Directory authentication (Kerberos TCP 88, LDAP TCP 389/636), DNS (UDP 53), file shares (SMB TCP 445 to specific servers), and email (SMTP TCP 25/587). It did not require access to the management VLAN, the DMZ, or the full server VLAN. The VPN ACLs should be reduced to permit only the specific protocols and destination hosts required for business operations.
In the longer term, the organisation should consider replacing the site-to-site VPN with a Zero Trust Network Access (ZTNA) model. ZTNA eliminates the concept of implicit network-level trust entirely. Instead of granting the satellite office access to entire network segments, ZTNA grants individual users access to individual applications based on their identity, device posture, and context. The satellite office's network becomes irrelevant — access decisions are made per-user, per-session, per-application.
Tiered administration must be enforced rigorously across all locations. Domain administrator accounts should never be used to log onto standard workstations — particularly at remote sites with reduced security controls. The RDP session that exposed the domain administrator credentials should never have existed on a satellite office workstation. A tiered model with dedicated Privileged Access Workstations for domain administration would have eliminated this vector entirely.
Finally, every site must be in scope for penetration testing. Testing only the head office creates a false sense of security. An attacker will not limit themselves to the best-defended location. They will find the weakest point in the architecture and use it. If the penetration test does not include satellite offices, branch locations, and acquired sites, then it is not testing the organisation — it is testing a subset of it.
The head office had spent years and significant budget building a mature security programme. EDR, SIEM, segmentation, LAPS, hardened configurations — the investments were real and they were effective. Our head office tester was substantially impeded by these controls.
But the satellite office existed in a parallel universe. Consumer hardware. Default credentials. No monitoring. No endpoint protection. An unlocked cupboard. And a VPN tunnel that treated it as a trusted extension of the head office network.
The organisation had built a fortress and then connected it to a garden shed with an open door. The fortress was impressive. The shed was where we walked in.
Until next time — stay sharp, stay curious, and remember: every tunnel has two ends. Check them both.
This article describes a penetration test conducted under formal engagement with full written authorisation from the client. All identifying details have been altered or omitted to preserve client confidentiality. The techniques described were performed within the scope of a legal agreement. Unauthorised access to computer systems is a criminal offence under the Computer Misuse Act 1990 and equivalent legislation worldwide. Do not attempt to replicate these techniques without proper authorisation.
Hedgehog Security tests the whole organisation — not just the head office. Branch offices, satellite locations, acquired sites, and remote infrastructure are where attackers look first because they know the security investment is thinnest. Let us show you what an attacker sees when they start at the weakest point.