Printer exploitation to gain access to Windows Domain

imagensecforcepost.png

Beware of the overlooked, unprotected, seemingly innocent network printers sitting in your office. They often disclose more information than social media on Game of Thrones.

With the continuous need to scan documents in the office, it is common practice to configure network folders within the network for storage, sharing and bookkeeping purposes.

It is also very common that printers are configured with domain user and SMTP login information to connect to domain resources and send scanned email attachments to employees’ inboxes. And speaking of spoilers, you can see where this is going..

LDAP, SMTP and NTLM

Consider the following setup:

print1.png

The domain share can be accessed with the login information stored within the printer’s web interface.

Spoofing

The first obvious attack vector is to use spoofing techniques in order to obtain the credentials. The attack will work only if we modify the network path and replace it with the attacking host’s IP address. Alternatively, we could resort to spoofing techniques (e.g. NetBios, LLMNR), where domain names are used, to point the network printer to the attacker’s host by replying to said broadcast queries.

The following steps were taken in a recent assessment to capture the LDAP credentials:

  1. Install/Configure an OpenLDAP server on a Linux VM mirroring the domain’s search root
  2. Log-in into the printer’s administration interface via default user/password credentials pair or access an unprotected configuration
  3. Browse to System Settings - Network Settings
  4. Replace the LDAP server value under LDAP settings Tab with the attacking VM’s IP address
  5. Change authentication method to Simple
  6. Start Wireshark on the Linux VM with the following display filter: tcp.port == 389
  7. The LDAP credentials should now appear in Wireshark

LDAP login information is very likely to grant an attacker access to an AD user account and by extension, domain resources.

print2.png

For NTLM creds:

1 - Launch an NTLM server on the attacker’s box (e.g. Responder, Metasploit’s auxiliary/server/capture/smb) which is listening for any connection

2 - Login onto the printer’s administration interface via default user/password credentials pair or navigate to the unprotected menu

3 - Browse to Scan < Network Folder Setup

4 - Replace the file server value under Network path with the attacker’s IP address

5 - Save and Test the connection

6 - The NetNTLMv2 hash is captured by the fake NTLM server

7 - Subject the hash to offline cryptanalysis to obtain the cleartext password or, depending on the configuration, use a relay module (https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html) to pass on the netNTLM hash and execute commands on remote hosts

print3.png

Add workstations to the domain Privilege

An often rather overlooked setting within the Active Directory is the privilege to add a workstation to the domain. This privilege is by default afforded to all domain users when it should only be a privilege of the workstation admins group. Following the attack outlined above in a recent engagement, we were able to use the low-privileged printer domain account so as to add an attacking Windows VM to the organisation’s domain and interact with its resources. Consequently, this opened the way for a plethora of other attacks and allowed us to elevate privileges through other attack vectors (Share-hunting, Kerberoasting, BloodHound, etc.).

It should also be mentioned that printers are very rarely monitored in the current landscape, so exploiting this functionality is likely to go unnoticed, unless the organisation has specifically invested in monitoring abnormal AD activity (e.g. ATA). In conclusion, a seemingly innocuous functionality within a printer is starting to have real, tangible and considerable impact on the internal domain’s security goals.

Best Practices and Recommendations

Small and large enterprises alike, should be mindful when choosing a network printer. A few things to consider

1 - Update and Patch

2 - Restrict Network Exposure

3 - Authentication

4 - Finally, consider restricting the administration services at a network level so that only connections from a network segment - much like, a management VLAN - are allowed. This way, only select workstations or hosts would have access to the configuration of the printers and the attack surface would be somewhat reduced.

You may also be interested in...

MSBuild-Logger-Code-Execution.png
Aug. 10, 2020

MSBuild logger code execution

Using msbuild to bypass application white-listing Is a well known and documented techique. You simply need to add some C# code to a msbuild task within an msbuild XML project file and msbuild will happily compile and run your code.

See more
imagensecforcepost.png
Dec. 5, 2012

Bring your own device (BYOD) security challenges

BYOD is a business policy which encourages employees to bring their personal devices (laptops, tablets, mobile phones) to the corporate environment and perform business tasks with them.

See more