PSO - When Printers Become the Pentester's Blindspot

The Printer Problem Nobody Talks About

Picture this: You’re three days into a pentest. The network scan returns 47 printers scattered across the corporate network. Your nmap output shows them clearly - ports 631 and 9100 wide open.

What do you do?

If you’re like most pentesters, you check if IPP is encrypted, note “lacks TLS” in your findings spreadsheet, assign it a MEDIUM severity, and move on. After all, they’re just printers. Right?

Wrong.

Two weeks after that particular engagement ended, our client called. They’d had a breach. The attackers didn’t exploit the vulnerable web server we’d flagged as CRITICAL. They didn’t crack any passwords. They didn’t need to.

They walked straight through the unpatched printer in the Finance department.

Inside that printer’s storage: 89 print jobs. Employment contracts. Salary spreadsheets. Acquisition plans. Customer financial data. All sitting there, accessible to anyone who thought to look.

The printer was in our report. Page 52. One line: “Printer lacks encryption (LOW).”

That’s when we realized something fundamental: We’re not actually testing printers. We’re just acknowledging they exist.

Why Printers Are the Perfect Blindspot

Printers occupy a strange space in network security. They’re:

Servers that nobody treats like servers:

Running 24/7 with persistent storage
Web interfaces with admin panels
File systems containing document history
Network services exposed to entire VLANs

Legacy protocol museums:

PJL (Printer Job Language) from the 1980s
PostScript with command execution capabilities
LPD with minimal authentication
SNMP community strings still at “public”

Update deserts:

Firmware patching? “If it prints, don’t touch it.”
Security updates? “We can’t afford downtime.”
EOL hardware? “But it still works…”

Treasure troves of sensitive data:

HR documents (terminations, performance reviews)
Financial records (payroll, budgets, tax documents)
Legal contracts (NDAs, acquisition terms)
Medical records (prescriptions, patient data)

Yet during pentests, they get the same superficial treatment every time. Why?

Because we lack the tooling to do it properly.

The Tools Gap

You can’t run sqlmap against a printer. Metasploit doesn’t have printer modules for modern attacks. Burp Suite won’t help you with binary IPP protocols. And the existing tools are either:

Too generic: Nessus will tell you CVE-2019-XXXXX exists. It won’t tell you if the printer has 47 stored jobs including Employee_Salaries_2025.xlsx.

Too specific: PRET is excellent for deep printer exploitation, but it’s manual, requires expertise, and isn’t workflow-friendly for standard pentest engagements.

Too old: Most printer security tools were written when printers actually used port 9100 exclusively. Modern enterprise environments use custom ports, cloud print services, and hybrid configurations.

The gap is real. And it’s costing our clients.

Enter PSO: Printer Security Offensive

We built PSO out of frustration. Not with clients, not with printers, but with ourselves.

Every pentest, same story: find printers, check encryption, move on. Meanwhile, the actual attack surface goes untested.

PSO is our answer to a simple question: What if we tested printers like we test everything else on the network?

What It Actually Does

Discovery that doesn’t miss things:

Modern networks don’t follow textbook configurations. That finance printer? It’s on port 8631 because “IT didn’t want port conflicts.” That executive printer? Port 19100 because “cloud print service needs it.”

PSO supports port ranges:

python pso.py --scan 10.0.0.0/24 --ports 443,631,5000-6000,9100

Find printers wherever they’re hiding.

Real exploitation testing:

PJL file system access is a known vulnerability. It allows unauthenticated directory listing of printer storage. Files, folders, everything. No credentials needed.

Most pentests don’t test for it because it requires:

Knowing the PJL command syntax
Sending binary data correctly
Parsing the response
Doing this for every printer manually

PSO automates it:

python pso.py 192.168.1.50 --aggressive

If vulnerable, you get instant CRITICAL findings with evidence.

The smoking gun finder:

Stored print jobs are the printer equivalent of database dumps just sitting on a server. They’re there, they’re accessible, and they’re full of exactly what attackers want.

PSO extracts job metadata:

Filenames (what documents were printed)
Usernames (who printed them)
Timestamps (when they were created)
High-risk keyword flagging (salary, confidential, patient, etc.)

Suddenly your printer finding isn’t “lacks encryption.” It’s “Finance printer contains 34 stored jobs including Employee_Salaries_2025.xlsx - CRITICAL.”

Workflow integration:

Because pentesting isn’t about cool techniques. It’s about findings that make it into reports that clients actually read.

# Your existing workflow
nmap -sV -p- 10.0.0.0/16 -oX scan.xml

# Add PSO
python pso.py --nmap scan.xml --aggressive --output json > printer_findings.json

# Or CSV for the spreadsheet warriors
python pso.py --nmap scan.xml --output csv > printers.csv

JSON for automation. CSV for reports. Table for quick review. Choose your poison.

Technical Deep Dive (For the Curious)

Binary IPP Protocol Implementation:

Most tools just hit /ipp/print over HTTP and hope. PSO speaks native IPP - the actual binary protocol. This means:

Accurate printer attribute extraction
Support for IPP-over-HTTP and IPPS (TLS)
Proper response parsing, not HTML scraping

PJL Protocol Handling:

@PJL INFO ID
@PJL FSDIRLIST NAME="0:/" ENTRY=1 COUNT=10

These aren’t just strings. They’re commands with specific formatting, timing, and response parsing requirements. PSO handles the protocol properly, not as an afterthought.

Intelligent Service Detection:

Found a printer on port 9999? PSO doesn’t assume. It:

Tests for PJL response
Sends IPP requests over HTTP
Tries IPPS over TLS
Updates protocol dynamically

No more “unknown service” dead ends.

CVE Database:

Real vulnerabilities from real vendors:

HP: CVE-2022-3942 (CRITICAL 9.8 - Buffer overflow)
Canon: CVE-2020-6796 (HIGH 7.5 - Info disclosure)
Xerox: CVE-2021-28673 (CRITICAL 9.1 - RCE via SMB)

YAML-based, easy to extend, sourced from official vendor advisories.

Real-World Impact

After deploying PSO in our engagements:

Before PSO:

Average printer findings per pentest: 3-5
Severity: MEDIUM (mostly “lacks encryption”)
Client action: “We’ll consider it in Q3”
Real security impact: Minimal

After PSO:

Average printer findings: 12-18
Severity: HIGH to CRITICAL (exploitable, with evidence)
Client action: “Fix this immediately”
Real security impact: Measurable

Example Findings We’ve Made

Finance Department (Week 2):

3 printers with PJL FS access enabled
127 stored jobs total
High-risk documents: payroll spreadsheets, salary negotiations, acquisition documents
Impact: Immediate remediation, policy changes, hardware replacement

Medical Clinic (Week 4):

Printer accessible from guest WiFi
89 stored jobs including patient records
HIPAA violation with audit trail
Impact: Network segmentation, printer firmware updates, compliance remediation plan

Law Firm (Week 6):

Legacy printer on port 8100 (would’ve missed it without port ranges)
Attorney work product stored in print queue
Client-privileged communication at risk
Impact: Printer decommissioned, data breach notification avoided

These aren’t theoretical. These are findings from actual engagements. Findings that wouldn’t exist without dedicated printer testing.

Why We’re Releasing It

Because this blindspot shouldn’t exist.

Security tools should be available to everyone doing security work. Keeping PSO internal benefits nobody except us. Releasing it benefits:

Pentesters: Better findings, faster assessments, evidence-based reports.

Blue teams: Understanding what attackers test for helps defend against it.

Organizations: More thorough security assessments lead to better security posture.

The industry: Open-source means peer review, contributions, and collective improvement.

Plus, honestly? We were tired of manually typing PJL commands.

Technical Details

Built with:

Python 3.11+ (modern, maintainable)
Native binary protocol implementations (no hacks)
Zero external dependencies for core functionality
MIT licensed (use it however you want)

Features:

Port range scanning (singles, lists, ranges)
Protocol auto-detection (PJL, IPP, IPPS)
PJL file system exploitation testing
Stored job metadata extraction
CVE database matching
Risk scoring (deterministic, explainable)
Multiple output formats (JSON, CSV, table)
nmap integration workflow
Windows UTF-8 support (because Windows)

What it’s not:

Not a replacement for PRET (different scope)
Not a printer management tool
Not for casual users (this is pentesting)
Not trying to do everything (focused scope)

Get Started

# Install
git clone https://gitlab.com/hivesecurity/pso-printer-security-offensive
cd pso-printer-security-offensive
pip install -r requirements.txt

# Quick scan
python pso.py --scan 192.168.1.0/24

# Full assessment
python pso.py 192.168.1.50 --check-jobs --aggressive --output json

# Workflow integration
nmap -sV -p- 10.0.0.0/16 -oX scan.xml
python pso.py --nmap scan.xml --aggressive --output csv > findings.csv

Repository: gitlab.com/hivesecurity/pso-printer-security-offensive

License: MIT

Docs: Full documentation in repo README

The Ethics Part

We need to talk about responsible use.

PSO includes exploitation capabilities (--aggressive mode). This isn’t pentesting theater - PJL FS access is real exploitation. Use responsibly:

Required:

Explicit written authorization
Defined scope including printer testing
Understanding that --aggressive crosses from assessment to exploitation

Not required:

Our permission (it’s MIT licensed)
Explaining your use case
Contribution back (though we’d love it)

Never acceptable:

Unauthorized testing
“But I was just curious” defenses
Ignoring the legal disclaimers

The tool is powerful. With power comes responsibility. Don’t be that person.

What’s Next

Roadmap (community-driven):

Enhanced vendor-specific parsers (more makes/models)
PRET integration for deeper exploitation
PDF report generation (executive-friendly)
Web dashboard (real-time monitoring)
More CVE sources (automated updates)

Want to contribute?

Bug reports and feature requests welcome
Pull requests appreciated
CVE additions needed (vendor expertise helps)
Real-world usage feedback invaluable

Final Thoughts

Printers have been the forgotten attack surface for too long. Not because they’re unimportant, but because we’ve lacked the tooling to test them properly.

PSO is our contribution to fixing that.

It’s not perfect. It’s not complete. But it’s real, it works, and it finds things that matter.

If it helps one pentester find one serious issue that wouldn’t have been caught otherwise, it’s worth releasing.

Because printers are servers too. And they deserve the same scrutiny we give everything else on the network.

PSO - Printer Security Offensive. Making printers visible, one pentest at a time.

Built by HiveSecurity. Released for the community. Available now on GitLab.

Comments & Discussion

Have you found printer vulnerabilities in your assessments? What tools do you use? Share your experiences in the comments below.

Tags: #pentesting #redteam #offensivesecurity #opensource #printersecurity