In a red team engagement, anything can be a target, and depending on what has already been looted (or not), everything will be a target - even as a form of desperation. In this stage of an engagement, a red team member may have to broaden their vision and should also bring peripherals into their scope, as they may also contain valuable information or loot. This happened during a red team engagement with the DT Security Red Team, which resulted in finding juicy information through a previously unknown CVE on an HP Printer.
As mentioned before, depending on how hardened the infrastructure may be, finding good loot for further access to the network may be scarce. The idea of targeting a printer revolves around the fact that multifunctional devices may resolve user accounts via ldap
and send their mail via smtp
, authenticating with at least a service account.
At first, during a red team assumed breach engagement, nothing of significant value was found on the internal network - services were all authenticated through Microsoft-SSO or other well-established OpenID Connect solutions (all patched and up to date).
Being frustrated and grasping onto every straw there was, the red team eventually came upon a multifunctional office printer shared by every worker in the remote office.
A detailed port scan revealed the typical open ports 80/443
and 9100
. Since connecting to port 9100
revealed nothing of interest, the team proceeded onto the printer’s built-in web server.
When clicking through the web interface, nothing concerning ldap
resolution was found, but it was discovered that the mail functionality was configured with a [email protected]
user!
Finally, something that might be of value - so of course the team attempted to edit the settings to see whether information regarding the scan account could be extracted. The edit page revealed the target SMTP-server, username and a password field:
Hoping that the web interface may disclose the password in any way was naturally…
… not crowned with success. =(
So the printer did not disclose the password via the web interface… But can we only change the remote SMTP server address while retaining all the other information including the unkown password stored in the printer?
We tried and:
It worked! We could change the target SMTP and still retain the user:password
already stored on the printer, resulting in a full disclosure of the credentials when run against a self-hosted plain
-authenticated SMTP server (as shown above).
-> So another question remains: Can anybody change these settings? Apparently not, as admin access is required, but the interface does not restrict you if it is configured without authentication or has default credentials.
Without disclosing too much confidential information, yes it was - and it led to the full compromise of a major business service the client offered. =)
Broadening your vision in a red team engagement may not only reveal new targets leading to a compromise of a service, but it can also end up with finding a CVE in a multifunctional printer.
Furthermore, restricting service accounts to their apparent use should be a given and should not be circumvented because some functions are convenient to use (disabling the whole concept).