When the Printer Became the Domain Administrator

It prints, it scans, it copies. It also stores your domain credentials.

Every organisation has them. They sit in corridors, in print rooms, beside tea stations, and in open-plan offices. They are large, beige, and unremarkable. Staff queue beside them waiting for their documents, swearing under their breath when the paper jams. Nobody thinks of the multifunction printer as a security risk. It is furniture. It is infrastructure in the same way that the carpet and the ceiling tiles are infrastructure — present, necessary, and entirely beneath notice.

And yet, within its plastic housing, the average enterprise multifunction printer contains a multi-core processor, gigabytes of storage, a full network stack, an embedded web server, an LDAP client, an SMTP client, SMB and FTP capabilities, and a configuration database that frequently stores domain credentials in recoverable form. It is, by any reasonable definition, a server — one that the IT department did not build, the security team does not monitor, and the vulnerability management programme does not scan.

This is the story of how one such device — a multifunction printer on the third floor of a professional services firm — handed us the keys to their entire Active Directory domain.

The Engagement Brief

The client was a mid-sized professional services firm — legal, accounting, and advisory — with approximately four hundred staff across three office locations. They had engaged us to conduct an internal network penetration test from their largest office, which housed the primary data centre and the majority of the IT infrastructure. The scope was an assumed-insider test: we were given a network drop on a general-purpose floor and tasked with determining how far a malicious insider or compromised endpoint could progress through the environment.

The client was reasonably mature in their security posture. They ran endpoint detection and response software on all workstations. They had a SIEM collecting Windows event logs. They enforced password complexity policies. They had recently completed a programme to remove local administrator rights from standard user accounts. They were confident that their environment would resist lateral movement.

They were right about the workstations. They had not considered the printers.

Initial Reconnaissance — The Usual Suspects

The first hours of the assessment followed our standard methodology. We connected to the network drop, confirmed we received a DHCP lease on the 10.1.3.0/24 VLAN — a general-purpose user VLAN — and began passive and active reconnaissance.

The client's security investments were immediately apparent. Workstations were running current builds of Windows with EDR agents visible in their service banners. SMB signing was enforced across the domain. LLMNR and NBT-NS had been disabled — our Responder instance sat silent, capturing nothing. 802.1X was not in place, but the EDR deployment and SMB hardening meant that our usual early-stage credential harvesting techniques were neutralised.

This is not uncommon on engagements against organisations that have invested in their security programme. It means we need to think differently. When the well-trodden paths are blocked, we look for the paths that nobody thought to defend.

We performed a broad service scan across the VLAN and two adjacent VLANs that were routable from our position. The scan returned workstations, a handful of servers on a separate VLAN (limited access — only DNS and authentication ports were reachable), and — distributed across all three VLANs — eleven multifunction printers.

The Printers — A Fleet of Servers

The eleven printers were a mix of two manufacturers, deployed across three floors. They were enterprise-grade multifunction devices — print, scan, copy, fax — the kind found in every professional office in the country. We enumerated the service profile of a representative device.

Eleven open ports. FTP with anonymous access. Telnet. SNMP. SMB. An embedded web server. JetDirect. Every one of these services represents an attack vector, and every one was present on all eleven devices across the estate.

The client's EDR solution did not cover the printers — it could not, as there is no EDR agent for an embedded printer operating system. The SIEM was not collecting logs from the printers. The vulnerability management scanner had the printer IP ranges excluded from its scope — a configuration choice made years ago to prevent scan-induced paper jams and reboots. The printers existed in a security blind spot of the organisation's own creation.

Default Credentials — The Front Door

We accessed the embedded web interface on port 443 and were presented with a login page. We tried the manufacturer's default administrative credentials — the username and password documented in the publicly available administrator guide.

The login succeeded on the first attempt. On seven of the eleven printers.

Seven of eleven enterprise multifunction printers were accessible with manufacturer default credentials. These were not newly installed devices — they had been in service for years. The default passwords had simply never been changed. The four devices with custom passwords had been configured by a different engineer during a later deployment phase, which is why they alone had been hardened.

The Configuration — Where Credentials Live

With administrative access to the embedded web interface, we began a systematic review of each printer's configuration. Enterprise multifunction printers require integration with corporate infrastructure to deliver their scanning, emailing, and authentication functions. That integration requires credentials — and those credentials have to be stored somewhere.

We found them in four places.

The prize was in the LDAP and SMB configurations. Both contained domain service account credentials. The question was whether we could extract the passwords from behind the masked fields in the web interface.

Extracting the Credentials

There are several well-documented techniques for extracting credentials from multifunction printers. The specific method depends on the manufacturer and firmware version. On this engagement, we employed three complementary approaches.

Configuration File Export

The administrative web interface provided a function to export the device's configuration as a backup file. This is a standard feature intended to allow administrators to clone configurations across multiple devices or restore settings after a firmware update. The exported file was an XML document containing every configuration parameter — including the LDAP bind password and the SMB service account password, both stored in a reversible encoding.

The LDAP bind password was encoded in Base64 — not encrypted, not hashed, simply encoded. Base64 is a representation format, not a security control. Decoding it is a single command. The password for the domain service account svc_printer_ldap was recovered instantly.

LDAP Passback Attack

For the devices where the configuration export did not yield plaintext-equivalent credentials, we employed an LDAP passback attack. The technique is elegant in its simplicity.

The printer's LDAP configuration page allows the administrator to specify the LDAP server address, the bind DN, and the bind password. We modified the LDAP server address to point to our testing laptop, where we had started an LDAP listener. We then clicked the 'Test Connection' button on the printer's web interface.

The printer, dutifully attempting to test its LDAP connectivity, connected to our listener and transmitted the bind credentials — including the password — in cleartext, because the LDAP configuration did not enforce TLS.

SNMP Configuration Dump

The SNMP service on the printers was configured with the default community string public for read access. Using snmpwalk against the manufacturer's private MIB extensions, we extracted additional configuration data including internal IP addressing, firmware versions, and — on certain firmware revisions — the SMTP authentication credentials used for the scan-to-email function.

Across the seven accessible printers, using these three methods, we recovered credentials for four distinct domain service accounts.

What Can a Service Account Do?

Four domain service accounts is a promising haul, but the value of a credential is determined by its privileges. We needed to understand what each account could access. Using the svc_printer_ldap credentials, we performed an authenticated LDAP query against the domain controllers to enumerate the accounts' group memberships and permissions.

The svc_printer_ldap account was a member of Domain Users and had read access to the full Active Directory tree. This alone was valuable — it allowed us to enumerate every user, every group, every computer object, every Group Policy Object, and every service principal name in the domain. In penetration testing terms, this is called a 'domain foothold' — a valid, authenticated position from which the entire directory structure becomes visible.

The svc_scan_smb account had write access to a network share named \\fileserver\scans. We accessed this share and discovered it contained thousands of scanned documents — contracts, invoices, HR records, financial statements, board minutes, and legal correspondence. The share had no access controls beyond the service account's write permission, meaning every document scanned by every user on every floor was accessible with this single credential.

But it was the svc_pullprint account that proved decisive.

The Pull-Print Account — Overprivileged by Design

The pull-print system required the service account to interact with Active Directory in ways that went beyond simple authentication. It needed to query user group memberships to enforce print quotas and departmental policies. It needed to manage print queues across multiple servers. It needed to create and modify printer objects in Active Directory.

To facilitate these requirements, the account had been granted membership in several privileged groups during initial deployment. Over the years, as troubleshooting occurred and permissions were added to resolve operational issues, the account had accumulated privileges far beyond its original scope.

The svc_pullprint account was a member of Print Operators, Server Operators, and Account Operators. These are highly privileged built-in Active Directory groups.

Print Operators can load printer drivers on domain controllers. This is a well-documented privilege escalation vector — a malicious printer driver loaded on a domain controller executes as SYSTEM, granting full control of the domain controller. Server Operators can log on to domain controllers locally and remotely, start and stop services, and manage shared resources. Account Operators can create, modify, and delete user accounts and groups within the domain.

Any one of these group memberships would be considered excessive for a print service account. Together, they represented a direct path to domain compromise.

Domain Compromise

We chose the Server Operators path as it was the most straightforward to demonstrate without triggering the client's EDR on workstations — our target was the domain controller directly, where the EDR agent was not deployed.

Using the svc_pullprint credentials, we authenticated to the primary domain controller at 10.1.1.10 via SMB. As a Server Operator, the account had the ability to modify existing services and create new ones on the domain controller. We used Impacket's services module to create a new Windows service that, upon execution, would run a command of our choosing as SYSTEM.

The service executed on the domain controller as SYSTEM. It created a new domain user account and added it to the Domain Admins group. We now had a domain administrator credential that we controlled.

To confirm the extent of access and demonstrate the full impact, we performed a DCSync attack using the new domain admin account — replicating all password hashes from the Active Directory database, including the krbtgt account.

Eight hundred and forty-seven domain accounts compromised. The entire Active Directory database extracted. From a printer.

From Paper Tray to Domain Admin

The Printer Problem

Multifunction printers are the most consistently overlooked devices in enterprise security. They are present in every organisation, they hold domain credentials by necessity, and they are almost universally excluded from the security controls applied to every other networked device.

The reasons for this exclusion are understandable but indefensible. Printers are managed by facilities or procurement teams, not IT security. They run proprietary embedded operating systems that cannot host EDR agents. Vulnerability scanners are excluded from printer ranges because aggressive scanning causes operational disruption. Firmware updates are deferred because they require physical interaction with each device and risk configuration loss. Default credentials persist because the admin interface is rarely accessed after initial setup.

The result is a fleet of devices, distributed across every floor of the organisation, each holding valid domain credentials, each running years-old firmware, each presenting an attack surface of a dozen or more open ports, and each invisible to every security control the organisation has deployed.

This is not a theoretical risk. This is the attack path we used to compromise a domain that had invested significantly in endpoint security, SIEM deployment, and workstation hardening. All of those controls were bypassed because the path to domain compromise did not pass through a workstation. It passed through a printer.

Technique Mapping

Recommendations and Hardening

The single most impactful remediation was the removal of the svc_pullprint account from privileged groups. This account had no legitimate need for Server Operators, Account Operators, or Print Operators membership. The privileges had been granted during troubleshooting years earlier and never revoked. A quarterly review of service account group memberships would have caught this — but no such review existed.

Group Managed Service Accounts (gMSA) should replace traditional service accounts for printer integration wherever the printer firmware supports them. gMSAs have their passwords managed automatically by Active Directory — rotated every 30 days, 240 characters long, and never known to a human. They eliminate the risk of stale, crackable, or extractable service account passwords entirely.

LDAP connections must use TLS. Without TLS, the LDAP passback attack is trivial. With TLS enforced and certificate validation enabled, the printer will refuse to connect to a rogue LDAP server, eliminating this credential extraction vector.

Finally, printers must be included in the organisation's vulnerability management programme. The argument that vulnerability scanning disrupts printer operation is a justification for tuning the scan profile, not for excluding the devices entirely. Credentialed scans with reduced aggressiveness can enumerate firmware versions and configuration weaknesses without causing paper jams or reboots.

Check your printers. Then check them again.

This client had done many things right. They had deployed EDR. They had enforced SMB signing. They had disabled LLMNR. They had removed local admin rights. These are meaningful, impactful security controls that would stop the majority of common internal attack paths.

But security is not a collection of individual controls — it is a system. And a system is only as strong as its weakest component. The weakest component in this environment was not a server, not a workstation, and not a firewall. It was a multifunction printer on the third floor, holding four sets of domain credentials, running firmware from three years ago, secured with the same default password it shipped with from the factory.

The printer did not care about the EDR deployment. The printer did not care about SMB signing. The printer existed outside every security control the organisation had built, and it held the credentials that made those controls irrelevant.

Until next time — stay sharp, stay curious, and never walk past a printer without wondering what it knows.