Key Takeaways

  • Multifunction printers (MFPs) routinely store domain credentials for scan-to-email, scan-to-folder, LDAP lookups, and FTP destinations - and most organizations never audit these configurations after initial setup.
  • Management interfaces like VNC, HTTP, and SNMP are frequently exposed without authentication, giving attackers direct access to view and modify printer configurations, including stored credential destinations.
  • Credential coercion from MFPs is a reliable path to domain compromise. During a recent engagement, unauthenticated VNC access to a Canon printer led to FTP credential coercion via Responder, ultimately leading to complete domain compromise within minutes.
  • Address books on MFPs often mirror the Global Address List (GAL), giving attackers a complete employee directory for targeted password spraying without ever querying Active Directory directly.
  • Printers live in a security blind spot — managed by IT operations, excluded from vulnerability management programs, and sitting on flat networks with full access to domain resources.

Every organization has them. They sit in hallways, break rooms, and server closets: multifunction printers quietly holding the credentials to your domain. While security teams focus on hardening servers, patching workstations, and locking down cloud environments, MFPs are out there storing service account passwords in configurations that haven't been reviewed since the day they were deployed.

During a recent penetration test, I turned a single unauthenticated printer management interface into domain admin. No CVEs, no zero-days - just a Canon printer with default configurations and a predictable chain of trust that most organizations never think to examine.

This isn't an edge case. Across hundreds of engagements, MFPs consistently provide some of the easiest and most reliable footholds into Active Directory environments. Here's how and why your printers are probably vulnerable right now.

Why Multifunction Printers Are a Great Target for Pentesters

MFPs are credential vaults that no one treats like credential vaults. To do their jobs, they need to authenticate to a surprising number of services:

  • SMTP servers for scan-to-email functionality
  • SMB file shares for scan-to-folder
  • FTP servers for scan destinations
  • LDAP directories for address book lookups and user authentication
  • Kerberos/NTLM for domain-joined print services

Every one of these integrations requires stored credentials, typically a domain service account. These credentials are configured once during deployment, usually by an IT administrator setting up the printer, and then forgotten. The service accounts are rarely scoped to least privilege. Password rotation policies rarely cover them. And the management interfaces protecting access to these configurations? Wide open more often than not.

It's a perfect storm: high-value credentials behind low-security controls on devices that no one is watching.

How Unauthenticated VNC on a Canon Printer Led to Domain Admin

During a recent engagement, I was scanning the internal network and came across a Canon imageRUNNER printer with VNC exposed on the network. No authentication required; I connected with a VNC viewer and had full access to the printer's touchscreen interface, remotely.

To the client's credit, they had rotated the default administrative credentials on the printer's web interface. The HTTP management console was locked down. Everything else looked reasonably secure. But VNC was wide open, and that was enough.

Discovering Stored FTP Credentials Through the Touchscreen

Navigating the printer's touchscreen interface through VNC, I found a configured server destination, an FTP target used for scan-to-folder workflows. The configuration showed the FTP server hostname and username, but the password was masked. I couldn't extract the credentials directly from the interface.

Here's what I could do: modify the destination host and test the connection.

The printer had a "Test Connection" button that would attempt to authenticate to whatever FTP server was configured. The password was stored so I just needed the printer to send it somewhere I controlled.

Coercing Credentials with Responder

I set up Responder on my attack machine to listen for incoming FTP authentication attempts:

sudo responder -I eth0 -v

Then, back in the VNC session, I modified the FTP destination host to point to my machine's IP address. I hit "Test Connection" and watched Responder light up.

[FTP] Client   : 10.10.10.10
[FTP] Username : svc_printscan
[FTP] Password : A1B2C3D4

The printer dutifully sent the stored FTP credentials to my machine. Not only did I now have the FTP credentials for the FTP server on the original target destination host, they were domain credentials.

From Printer Credentials to Domain Admin

With a valid domain account in hand, the path forward was straightforward. I ran BloodHound to map the Active Directory environment:

bloodhound-python -u svc_printscan -p '<password>' -d corp.local -ns 10.10.10.1 -c all

The service account had more privileges than a scan-to-folder account should ever need. BloodHound revealed a clear escalation path from the compromised service account to domain admin. Within minutes, what started as an overlooked printer became full domain compromise.

The fix for the VNC exposure was trivial. The damage it enabled was not.

How Konica Minolta BizHub Printers Give Up Domain Credentials Without a Fight

Canon printers aren't alone in this. Konica Minolta BizHub MFPs are some of the worst offenders I encounter on engagements - and the issue goes beyond credential coercion. These devices store SMB and FTP credentials for scan-to-folder destinations in a way that allows direct extraction through the web interface.

Dumping Stored Credentials with Metasploit

Konica Minolta BizHub devices store domain credentials for their SMB and FTP scan destinations in memory, and those credentials can be pulled directly using Metasploit's auxiliary/gather/konica_minolta_pwd_extract module. The module sends SOAP XML requests to the printer's web interface and extracts the stored usernames and passwords for every configured scan destination.

msf6 > use auxiliary/gather/konica_minolta_pwd_extract
msf6 auxiliary(konica_minolta_pwd_extract) > set RHOSTS 10.10.15.50
msf6 auxiliary(konica_minolta_pwd_extract) > run

This works against a wide range of BizHub models including the C224, C280, C353, C360, C452, C454e, C554, and others have all been confirmed vulnerable. If the web management interface is accessible with default credentials (the admin password on many BizHub models ships as 12345678), the module dumps every configured FTP and SMB credential in cleartext.

No coercion needed. No modifying destinations. The printer just hands over the stored passwords.

Pass-Back Attacks When Direct Extraction Isn't an Option

When direct credential extraction isn't possible, maybe the firmware is newer or the admin password has been changed, BizHub devices are still vulnerable to pass-back attacks. The same pattern applies here: access the management interface, modify the SMB or LDAP destination to point to your machine, and trigger a connection test to coerce the stored credentials.

This is such a persistent issue that Rapid7 published CVE-2025-6081 specifically for the LDAP pass-back variant on BizHub devices - and as of the disclosure, Konica Minolta has not released a fix. The credentials transmit in cleartext when the device authenticates to the attacker's LDAP listener, making interception trivial.

Why BizHub Credentials Are Almost Always Domain-Valid

The service accounts configured on these devices are almost always domain-joined. They have to be - scan-to-folder over SMB authenticates against Active Directory, and LDAP lookups bind with a domain account. On multiple engagements, I've found these accounts with far more access than writing a scanned PDF to a file share requires. They become instant pivot points into the domain.

How LDAP Configurations on MFPs Expose Service Account Credentials

Many MFPs use LDAP to provide address book lookups and user authentication at the device. This requires an LDAP bind account - another domain service account with stored credentials.

LDAP configurations on printers are exploitable in two ways:

  1. Direct credential exposure: Some printer models display the LDAP bind password in cleartext through the management interface. I've seen this on older firmware versions where navigating to the LDAP configuration page simply shows the password in a form field.
  2. Credential coercion: Same technique as FTP and SMB. Modify the LDAP server address to point to your machine, trigger a connection test, and capture the bind credentials with Responder or a similar tool.

LDAP bind accounts are often over-privileged because the printer needs to search the directory broadly - it needs to look up any user who walks up to the device. This frequently translates to accounts with read access across the entire directory, which is more than enough for an attacker to enumerate every user, group, and computer object in Active Directory.

How Printer Address Books Give Attackers Your Entire Employee Directory

Even when stored credentials aren't directly accessible, MFPs often leak something nearly as valuable: your organization's Global Address List (GAL).

Many MFPs sync their local address books from Active Directory via LDAP. This means the printer's address book contains every email address, and often the full name and department, of every user in the organization. On most devices, this address book is accessible through the management web interface without authentication.

This gives an attacker a complete, accurate user list for password spraying. No need to query LDAP directly (which might be monitored), no need to scrape LinkedIn (which is incomplete), and no need to guess naming conventions. The printer just hands over the entire directory.

During engagements, I've pulled address books from MFPs that contained hundreds of email addresses, perfectly formatted for a spray attack against OWA, VPN portals, or any other service using Active Directory authentication. Combined with commonly used passwords or seasonal patterns, this frequently results in valid credentials.

Why MFPs Keep Falling Through the Security Cracks

These aren't sophisticated attacks. There are no zero-days here, just predictable misconfigurations that persist because printers occupy a unique blind spot in most security programs:

  • Ownership gap: Printers are managed by IT operations or facilities, not the security team. Security reviews rarely include printer configurations.
  • Default configurations ship insecure: Most MFPs enable management protocols (HTTP, SNMP, VNC, Telnet) by default with no authentication required. The assumption is that the admin will lock these down but often no one tells the admin to do that.
  • Flat network placement: Printers sit on the same network segments as workstations and servers. They can reach domain controllers, file shares, and internal services without restriction.
  • Excluded from vulnerability management: Printers rarely show up in vulnerability scanning programs. Even when they do, the findings are deprioritized because "it's just a printer."
  • Stale configurations: The service accounts and destinations configured during deployment persist for years. Credentials don't get rotated. Unnecessary integrations don't get removed. No one goes back to ask whether the printer still needs FTP access to a server that was decommissioned two years ago.
  • Firmware update neglect: Printer firmware updates are rarely applied, leaving known vulnerabilities unpatched for the lifetime of the device.

How to Lock Down Your MFPs Before a Pentest

The good news is that these issues are straightforward to remediate. The challenge is making MFP security part of your operational practice rather than a one-time cleanup:

  1. Disable unnecessary management protocols. Turn off VNC, Telnet, SNMP v1/v2, and any other management interface that isn't actively needed. If web management is required, enforce HTTPS with strong authentication.
  2. Require authentication on every management interface. No exceptions. If a protocol can't be password-protected, disable it.
  3. Use dedicated, least-privilege service accounts. Each printer function (scan-to-email, scan-to-folder, LDAP lookup) should use a separate service account with the minimum permissions required. A scan-to-folder account doesn't need domain admin rights - it needs write access to one share.
  4. Segment your printer network. MFPs should be on their own VLAN with firewall rules restricting what they can communicate with. A printer needs to reach the mail server and maybe a file share. It doesn't need unrestricted access to the entire internal network.
  5. Include printers in your security audits. Review printer configurations at least annually. Check for exposed management interfaces, unnecessary stored credentials, and overly permissive service accounts.
  6. Monitor for credential coercion. Alert on unusual SMB, FTP, or LDAP authentication attempts originating from printer subnets. If your Canon printer is suddenly authenticating to a host that isn't your FTP server, something is wrong.
  7. Apply firmware updates. Treat printer firmware like any other software in your environment. Patch it.Printers Are Infrastructure — Treat Them Like It

MFPs aren't peripherals anymore. They're networked devices that authenticate to Active Directory, store domain credentials, and have management interfaces as capable as many servers. The moment we started giving printers service accounts and network access, they became infrastructure but most organizations still treat them like furniture.

Every MFP finding I've described in this article came from a real engagement. These aren't theoretical risks. They're tested, validated attack paths that consistently lead to domain compromise across environments of all sizes. And they persist because printers live outside the security team's line of sight.

If you haven't audited your MFP configurations recently, now is a good time to start. Or better yet, let us find out what your printers are giving away before someone else does.