Skip to content

fix: ensure USERPASS_FILE credentials store password (set private_type) - #20553

Merged
smcintyre-r7 merged 1 commit into
rapid7:masterfrom
BenoitDePaoli:fix/userpass_password_persistence
Sep 18, 2025
Merged

fix: ensure USERPASS_FILE credentials store password (set private_type)#20553
smcintyre-r7 merged 1 commit into
rapid7:masterfrom
BenoitDePaoli:fix/userpass_password_persistence

Conversation

@BenoitDePaoli

@BenoitDePaoli BenoitDePaoli commented Sep 17, 2025

Copy link
Copy Markdown
Contributor

Summary:

Fix a bug where credentials sourced from USERPASS_FILE were not reliably persisted with their passwords in the Metasploit credential database.

The yielded credentials from each_user_pass_from_userpass_file did not set private_type, so the framework didn’t persist the password as a Metasploit::Credential::Password.
This PR makes ensures private_type is always set for USERPASS_FILE credentials.

Reproduction

Behavior Before Fix

Create a file:

postgres password

Run an AuthBrute-based module, (postgres_login, mssql_login ...):

use auxiliary/scanner/postgres/postgres_login
set RHOSTS <target>
set USERPASS_FILE /path/to/file
run

After a successful attempt, run:

creds

Password is missing (blank / not stored).

image

Behavior After Fix

The same steps now show password under the private column in creds output:

creds

Password is present and stored.

image

@BenoitDePaoli
BenoitDePaoli marked this pull request as ready for review September 17, 2025 12:57
@BenoitDePaoli
BenoitDePaoli force-pushed the fix/userpass_password_persistence branch from 918bd0c to 08c4367 Compare September 17, 2025 13:42
@smcintyre-r7 smcintyre-r7 self-assigned this Sep 18, 2025

@smcintyre-r7 smcintyre-r7 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this submission. I was able to reproduce the original issue then validate the fix addresses it. I did notice that this doesn't seem to affect every bruteforce module because some such as smb_login do their own detection on the private to report its type.

...
[-] 192.168.159.128:15432 - LOGIN FAILED: admin:password@template1 (Incorrect: FATAL	VFATAL	C28P01	Mpassword authentication failed for user "admin"	Fauth.c	L329	Rauth_failed)
[-] 192.168.159.128:15432 - LOGIN FAILED: admin:admin@template1 (Incorrect: FATAL	VFATAL	C28P01	Mpassword authentication failed for user "admin"	Fauth.c	L329	Rauth_failed)
[+] 192.168.159.128:15432 - Login Successful: postgres:mysecretpassword@template1
[*] Scanned 1 of 1 hosts (100% complete)
[*] Bruteforce completed, 1 credential was successful.
[*] You can open a Postgres session with these credentials and CreateSession set to true
[*] Auxiliary module execution completed
msf auxiliary(scanner/postgres/postgres_login) > creds
Credentials
===========

id   host             origin           service               public    private           realm      private_type  JtR Format  cracked_password
--   ----             ------           -------               ------    -------           -----      ------------  ----------  ----------------
528  192.168.159.128  192.168.159.128  15432/tcp (postgres)  postgres  mysecretpassword  template1  Password

msf auxiliary(scanner/postgres/postgres_login) > 

@smcintyre-r7
smcintyre-r7 merged commit ed88e53 into rapid7:master Sep 18, 2025
20 checks passed
@smcintyre-r7

Copy link
Copy Markdown
Contributor

Release Notes

This fixes a bug that was preventing the private type of stored credentials to be omitted in certain conditions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

easy library rn-fix release notes fix

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

2 participants